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Abstract 

This  research  defines  and  analyzes  a  simple  language  for  parallel  programming 
which  Is  designed  for  multiple  processor  systems.  The  language  (EBL)  is  based  on  events 
which  provide  the  only  control  mechanism.  Events  are  explicitly  caused  by  the  program,  and 
they  activate  Instances  of  dynamic  program  units  called  event  handlers.  The  only  operation 
that  can  be  performed  by  an  Instance  of  an  event  handler  is  the  causing  of  new  events. 
The  language  constructs  are  primitive;  nevertheless,  the  capability  of  hierarchical  program 
design  Is  provided  via  static  modules  and  other  modularity  sources. 

The  language  does  not  contain  conventional  constructs  such  as:  variables, 
assignment  statements,  goto  statements,  iteration  constructs,  procedures,  functions,  and 
semaphores;  however,  these  can  be  easily  modeled.  In  addition,  events  allow  activation  of 
parallel  processes,  synchronization  of  parallel  processes,  mutual  exclusion,  message 
passing,  Immutable  objects,  and  the  effect  of  mutable  objects. 

Schemes  for  Implementation  of  the  language  on  processor  networks  are 
Investigated.  An  implementation  scheme  based  on  communicating  managers  which  operate 
without  any  centralized  control  is  described.  A  relaxed  distributed  locking  algorithm  in  which 
deadlocks  are  prevented  is  developed;  It  does  not  assume  a  total  order  on  all  objects  to  be 
locked.  Several  optimization  problems,  e.g.,  optimal  distribution  of  objects  In  a  network,  are 
Investigated.  The  problems  are  shown  to  be  NP- hard  and  heuristic  algorithms  are  suggested. 
Implementation  schemes  of  the  language  on  a  data  flow  processor  are  described.  These 
add  to  the  processor  the  capability  of  procedures,  and  synchronization  primitives  such  as 
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Section  1 


1.  Introduction 

The  research  described  in  this  thesis  deals  in  the  first  part  with  EBL,  an  event 
based  language  for  parallel  programming  which  Is  designed  for  multiple  processor 
applications,  and  in  the  second  part  with  strategies  for  Its  implementation  on  multiple 
processor  systems. 

1.1  Motivation 

The  decreasing  cost  of  computer  hardware  will  cause  building  of  more  and  more 
multiple  processor  systems  of  various  kinds.  Examples  of  such  systems  are:  C.mmp  [Wu-72], 
Pluribus  [He-73],  Data  Flow  [De-76],  the  boolean  n-cube  parallel  machine  [Su-77],  and  the 
MuNet  [Wa-78b].  However,  most  of  today's  programming  languages  are  not  designed  to 
exploit  the  concurrent  processing  capabilities  offered  by  such  systems. 

The  classical  languages  such  as  ALGOL,  or  FORTRAN  do  not  support  parallelism  at 
all.  PL/1  has  a  multi-tasking  capability,  therefore  one  can  easily  express  in  the  language  a 
process  spawning  concurrent  processes.  Unfortunately,  the  language  lacks  adequate 
primitives  for  synchronization  of  concurrent  processes  [Mo-76].  It  does  not  provide,  for 
example,  any  mechanism  supporting  mutual  exclusion;  thus,  to  achieve  mutual  exclusion 
among  concurrent  processes  one  must  resort  to  some  form  of  busy  waiting,  a  solution  which 
wastes  computational  resources. 

More  modern  languages  such  as  MODULA  [Wi-77b],  CONCURRENT  PASCAL 
[BH-75],  and  communicating  sequential  processes  [Ho-78a]  provide  for  parallelism  (as  well 
as  synchronization  primitives),  but  only  In -the  limited  form  of  sequential  processes.  These 


,* 
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languages  have  certain  disadvantages:  In  MODULA  only  the  main  process  can  activate  other 
processes,  thus  the  rate  of  spawning  new  activities  is  limited.  Communicating  sequential 
processes  is  a  static  language.  The  maximum  number  of  concurrent  processes  is  bounded, 
and  the  set  of  processes  with  which  a  process  can  communicate  is  fixed  and  can  be  found 
from  the  program  text. 

Languages  based  on  message  passing  models  of  computation  such  as  the  Actor 
model  [He-76]  do  not  suffer  from  the  above  disadvantages.  Our  model  is  reminiscent  of 
message  passing  models  but  there  are  some  fundamental  differences  which  are  discussed  in 
section  1.5. 

1 .2  Research  Goals 

The  language  design  goals  have  been; 

1.  High  expressive  power  and  universality,  especially  suitable  for  expressing 
parallel  computations  in  a  distributed  processing  environment. 

2.  A  small  number  of  constructs,  even  to  the  extent  of  obtaining  only  a  base 
language. 

3.  The  capability  of  hierarchical  (top  down)  program  design,  and  the  ability  of 
creating  encapsulated  program  units  that  can  be  designed  and  checked  in  a 
modular  way.  Such  features  are  especially  Important  in  a  language  for  parallel 
programming. 

4.  A  reasonable  implementation;  although  the  language  has  not  been  implemented, 
implementation  issues  influenced  many  of  the  decisions  made  during  the  design. 


-  + 


i«n  inmijnj* 

"  '■  . 


Research  Goals  -  1 3  -  Section  1 .2 

Another  goal  of  this  research  has  been  the  investigation  of  strategies  for 
implementation  of  the  language  on  multiple  processor  systems.  Our  primary  interest  has  been 
the  exploitation  of  concurrency  within  programs;  therefore,  we  have  concentrated  on  two 
types  of  systems  which  seem  suitable:  a  processor  network,  and  a  data  flow  processor 
[De-77].  A  processor  network  is  attractive  not  only  because  of  its  potential  computing 
power,  but  also  because  of  its  scaling  characteristics.  In  contrast  to  conventional  systems, 
a  processor  network  is  not  limited  by  dependencies  on  shared  resources  which  become 
bottlenecks  as  the  system's  size  increases  [Wa-78b].  The  data  tIow  processor  has  been 
selected  since  it  is  designed  to  achieve  a  highly  parallel  operation.  Our  implementation 
schemes  are  not  restricted  to  the  above  types  of  systems;  they  can  be  easily  adapted  to 
other  systems. 

1 .3  Our  Approach 

Our  approach  to  the  language  design  was  partially  motivated  by  our  desire  to 
investigate  the  intrinsic  power  of  events.  We  asked  ourselves  whether  a  language  in  which 
events  provide  the  only  control  mechanism  can  be  designed,  or  whether  additional 
constructs  are  essential.  In  order  to  find  the  answer  we  tried  to  see  what  is  the  inherent 
power  of  events:  what  do  they  capture,  what  computations  can  be  expressed  in  a  language 
using  only  events,  and  which  conventional  control  structures  can  be  expressed  In  terms  of 
events.  We  approached  the  problem  by  going  almost  to  the  extreme  case.  The  defined 
language  is  very  condensed  and  it  has  no  conventional  control  structures  or  data  structures. 
In  particular,  the  language  does  not  contain  variables,  assignment  statements,  goto 
statements,  Iteration  constructs,  procedures,  or  functions. 
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Our  approach  to  implementation  of  the  language  has  been  to  exploit  the  various 
sources  of  parallelism  In  a  program.  For  this  reason  schemes  relying  on  centralized  control 
have  not  been  considered.  Instead,  our  basic  Implementation  scheme  Involves  many 
managers  communicating  with  each  other.  The  role  of  a  manager  Is  limited;  each  manager 
handles  one  event  class  or  one  (normally  small)  program  unit. 

Distributed  implementations  are  harder  than  single  processor  Implementations. 
One  encounters  more  difficulties  when  implementing  a  distributed  database  than  in  the  case 
of  a  conventional  (single  processor)  database.  The  price  paid  for  achieving  higher 
concurrency  (as  well  as  other  advantages)  In  the  case  of  a  distributed  database  is  that 
some  of  the  operations  require  special  mechanisms  for  their  correct  Implementation.  For 
example,  locking  of  objects,  and  maintaining  consist- .ncy  are  more  difficult  to  implement  In  a 
distributed  system.  It  is  not  surprising,  therefore,  that  similar  problems  have  been 
encountered  in  the  course  of  designing  implementation  schemes  for  our  language.  Various 
techniques  have  been  devised  in  this  research  for  solving  these  problems. 

1.4  The  Event  Model 

Other  formalizations  of  the  event  notion  have  been  done  by  several  message 
passing  models  of  computation,  e.g.,  the  Actor  model  [He-76],  and  the  mu  calculus  [Ha-78, 
Wa-78a].  Their  notion  of  event  differs  from  ours  and  the  differences  are  discussed  in 
section  1 .5.  The  following  description  of  our  model  is  not  formal;  our  language  formalizes  it. 
Only  the  fundamental  properties  of  our  model  are  described  in  this  section;  many  of  the 
features  are  abstracted  (some  of  them  are  given  In  the  next  chapter)  and  only  those 
needed  for  comparison  with  other  models  of  computation  are  given. 
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In  our  model,  events  are  abstract  entities  that  are  explicitly  caused  oy  the 
program  during  the  course  of  the  computation.  An  event  object  Is  created  upon  each 
occurrence  of  an  event  and  it  carries  Information  on  the  nature  of  Its  occurrence.  The 
occurrence  of  an  event  can  be  remembered  forever,  i.e.,  the  corresponding  event  object  Is 
permanent,  or  can  be  forgotten  at  some  stage  of  the  computation,  I.e.,  the  corresponding 
event  object  Is  temporary.  The  distinction  between  these  two  kinds  of  behavior  is  done 
syntactically,  on  the  basis  of  explicitly  declared  types.  In  the  fo-mer  case,  an  event  may 
have  several  direct  effects  and  it  is  called  a  multi__use  event.  In  the  latter  case,  it  may 
have  at  most  one  direct  effect  after  which  It  Is  forgotten;  in  this  case  the  event  Is  a 
single_use  event.  A  direct  effect  of  an  event  is  the  activation  of  an  instance  of  a  program 
unit  (an  event  handler).  In  our  model  the  program  consists  of  fixed  program  units  (the 
number  of  program  units  and  their  identities  are  fixed);  an  Instance  of  a  program  unit  Is 
activated  when  several  events  satisfying  some  condition  specified  by  the  program  unit  have 
occurred.  Once  an  Instance  of  a  program  unit  is  activated  it  causes  some  events  and  then 
vanishes. 


The  occurrence  of  an  event  is  brought  to  knowledge  of  (broadcast  to)  all  program 
units  and  thus  may  activate  instances  of  more  than  one  program  unit  (if  the  corresponding 
event  object  is  permanent),  each  causing  more  events.  The  information  about  the  nature  of 
an  event  occurrence  cannot  be  modified:  It  either  remains  unchanged  forever  (if  the  event 
object  Is  permanent),  or  is  totally  forgotten  (if  the  event  object  is  temporary).  The  latter 
happens  when  the  event  activates  an  instance  of  a  program  unit;  one  of  the  effects  of  such 
activation  can  therefore  be  thought  of  as  uncauslng  (forgetting)  the  event.  The  ability  to 
uncause  an  event  introduces  mutable  objects  to  the  model,  and  this  will  be  examined  in 
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An  Instance  of  a  program  unit  causing  an  event  does  not  know  and  has  no  control 
over:  whet  program  units  wtN  be  affected  by  it,  how  many  Instances  of  program  units  will  be 
affected,  and  when  wW  they  be  affected.  Each  program  unit  knows  which  events  have 
occurred  so  far  and  thus  can  autonomously  decide  which  of  them  Is  relevant  to  it  and  should 
affect  it.  In  this  respect,  program  units  are  reminiscent  of  daemons  (event  driven 
procedures;  see  for  example  [Pf-74,  Wi- 7  7a]),  or  knowledge  sources  of  Hearsay  [Le-76]. 

In  our  model  as  presented  so  far,  there  is  basically  one  global  environment  for 
events  accessible  to  all  program  units.  This  Is  different  from  models  supporting  local  (or 
nested)  environments  such  as  block  structured  languages,  the  lambda  calculus,  or  the  mu 
calculus,  where  the  structure  of  the  program  determines  the  various  environments. 

The  main  advantage  of  a  global  environment  is  that  every  program  unit  can 
access  all  objects,  and  thus  all  program  units  can  communicate  with  each  other.  Such 
unrestricted  access  capabilities  add  to  the  expressive  power  of  the  language,  e.g.,  in 
comparison  to  the  mu  calculus  where  a  message  can  be  only  sent  to  nested  receivers.  On 
the  other  hand,  the  lack  of  local  environments  has  several  disadvantages  such  as:  lack  of 
modularity  on  its  various  aspects  (e.g.,  local  name  spaces,  local  objects,  protection  of 
objects,  abstract  data  types,  or  encapsulated  program  units),  or  lack  of  temporary  objects 
(i.e.,  bad  storage  utilization). 

Our  language  manifests  some  compromise  between  one  global  environment  and 
local  environments.  It  contains  several  mechanisms  (e.g.,  modules,  event  classes,  formal 
parameters)  which  eliminate  some  of  the  disadvantages  of  a  global  environment  while 
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allowing  the  programmer  to  control  the  extent  to  which  objects  are  accessible  to  program 

units. 

5- 

Modularity  is  manifested  in  several  forms  in  the  language.  The  first  source  of 
modularity  stems  from  our  modules  (which  are  defined  in  the  next  chapter).  Modules  allow 
hiding  and  sharing  of  identifiers  between  program  units,  protection  of  object  classes  (event 
classes)  against  undesired  uses,  creating  encapsulated  prof,  am  units  and  abstract  data 
types,  top  down  and  bottom  up  designs. 

Another  source  of  modularity  (bette.  called  freedom)  stems  from  the  fact  that  the 
order  of  program  units  (event  handlers)  in  the  program  has  no  effect  on  the  meaning  of  the 
program.  This  relaxes  the  constraint  of  most  existing  programming  languages  where 
consecutive  steps  In  an  algorithm  are  typically  adjacent  in  the  program  text  (except  where 
transfer  of  control  occurs).  In  cur  case,  the  algorithm  for  handling  an  event  can  be 
distributed  in  the  program  text.  This  freedom  does  not  nec.’S'arlly  contribute  to  program 

*  modularity;  however,  it  allows  the  program  to  be  organlzeded  in  some  meaningful  structure. 

$  For  example,  a  real  time  program  fcr  controlling  a  physic- 1  system  such  as  a  car,  can  be 

constructed  as  a  collection  of  modules  that  reflects  the  stiucture  of  the  physical  system; 

V  . 

i  each  program  module  will  correspond  to  some  physical  module.  On  replacement  of  one 

physical  module,  only  the  corresponding  program  module  has  to  be  modified. 

f 

V 

K 

jf 


f 


Section  1.5 


-  18  - 


Relation  to  Message  Passing  Models 


1 .5  Relation  to  Message  Passing  Models 

A  possible  way  to  understand  this  model  is  by  describing  its  behavior  in  terms  of 
message  passing  models  such  as  the  Actor  model  [He-76],  or  the  mu  calculus  model  [Ha-78, 
Wa-78a].  The  basic  computational  step  in  a  message  passing  model  is  passing  a  message 
from  one  instance  of  a  program  unit  to  another  instance  of  a  program  unit.  In  the  event 
model,  the  basic  computational  step  is  causing  an  event  by  one  instance  of  a  program  unit. 
This  can  be  thought  of  as  broadcasting  a  message  to  some  ether  enclosing  all  program  units 
(akin  to  ETHER  [Ko-79]).  Another  way  to  understand  It  is  as  writing  something  on  a 
blackboard  accessible  to  all  program  units  (akin  to  Hearsay  [Le-75]). 

Our  basic  computational  step  does  not  Include  the  receipt  of  the  message  by 
other  program  units  since  no  explicit  target  is  associated  with  the  message.  Therefore,  our 
basic  computational  step  consists  only  of  broadcasting  the  message  to  the  ether.  The 
message  describes  the  nature  of  the  event  occurrence;  it  carries  both  values  and  control 
Information.  A  program  unit  (conceptually)  continuously  examines  the  ether  and  when  It 
finds  a  collection  of  relevant  messages,  an  Instance  of  the  program  unit  is  activated. 

We  distinguish  between  permanent  and  temporary  messages.  A  message  of  the 
first  kind  cannot  be  removed  from  the  ether  (erased  from  the  blackboard);  It  can  be 
examined  by  more  than  one  program  unit,  and  cause  activation  of  several  instances  of 
program  units.  A  message  of  the  second  kind  is  deleted  from  the  ether  when  it  causes  the 
activation  of  an  instance  of  a  program  unit.  In  both  cases,  a  message  In  the  ether  Is  an 
Immutable  object  since  it  describes  the  nature  of  a  past  event. 
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A  program  unit  can  remove  from  the  ether  one  or  more  messages  (uncause  one  or 
more  singie_use  events)  in  an  atomic  action.  This  sllows  easy  solutions  to  synchronization 
problems  such  as  the  five  dining  philosophers  (see  chapter  6).  A  program  unit  need  not 
specify  the  order  in  which  it  processes  messages  'events)  from  a  certain  class;  this  can  be 
left  for  the  system.  However,  a  program  unit  can  specify  some  desired  order,  e.g.,  a  FIFO 
order.  Other  orders  can  be  specified  and  this  allows  easy  solutions  to  scheduling  problems 
such  as  the  (minimum  distance)  disk  head  scheduler  (see  chapter  6). 

Some  of  the  fundamental  differences  between  EBL  and  languages  based  on  the 
Actor  model,  PLASMA  [He-76]  and  Actl  [He-79],  are  discussed  now. 

1 .  The  concept  of  event  is  different.  In  the  Actor  model,  an  event  Is  defined  as  the 
receipt  of  a  message  by  an  actor,  whereas  In  EBL's  model,  the  occurrence  of  an 
event  can  be  associated  with  the  transmission  of  a  message  (an  event  object). 

2.  A  message  in  the  Actor  model  specifies  an  explicit  target,  whereas  no  target  is 
specified  by  an  EBL  event.  This  allows  the  same  message  (event)  to  be 
detected  by  more  than  one  program  unit  and  thus  adds  to  the  expressive  power 
of  EBL.  The  price  for  this  is  paid  by  the  receivers  which  have  to  find  the 
messages  in  which  they  are  interested. 

3.  Events  in  EBL  (more  precisely  event  clashes)  are  named,  while  the  Actor  model 
has  no  mechanism  for  naming  events  or  messages.  This  allows  a  program  unit  to 
specify  the  message  classes  in  which  It  is  interested.  This  capability  adds  to  the 
expressive  power  but  the  tradeoffs  are  similar  to  those  related  to  the  lack  of 
explicit  targets. 

4.  EBL  Is  strongly  typed  while  PLASMA  is  not  a  typed  language.  There  Is  a  greater 
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programming  freedom  in  a  non-typed  language;  however,  fewer  checks  can  be 
dona  at  compile  time,  and  certain  run  time  errors  that  could  have  been  detected 
at  compile  time  may  occur  In  a  non-typed  language.  Note  that  Actl  is  a  typed 
language. 

5.  Messages  (event  objects)  In  EBL  are  restricted,  and  must  be  of  fixed  types.  In 
the  Actor  model,  the  structure  of  a  message  M  sent  from  actor  A  to  actor  B  is  not 
restricted.  The  message  M  can  be  any  actor;  it  can  carry  data  or  even  an 
explicit  algorithm  that  B  can  activate.  A  possible  analogue  In  EBL  would  be 
allowing  an  event  handler  as  a  parameter  of  an  event.  We  have  not  included 
such  a  capability  in  EBL  because  it  complicates  the  language  and  Its  usefulness 
is  not  apparent. 

8.  In  EBL  there  Is  a  complete  separation  between  algorithms  and  state  information 
(control  or  data)  they  need  for  their  execution.  Algorithms  are  represented  by 
event  handlers  which  are  therefore  pure,  and  all  state  information  is  represented 
by  events.  In  the  Actor  model  the  separation  exists  only  for  unserialized  actors 
since  a  serialized  actor  has  a  state  associated  with  it.  In  general,  a  pure 
algorithm  has  an  advantage  in  a  distributed  system  since  multiple  copies  of  it  can 
be  kept  in  the  system  and  each  can  be  activated  whensver  the  information  it 
needs  arrives. 

7.  EBL's  feature  of  one  (multi_use)  event  directly  activating  several  instances  of 
event  handlers,  has  no  analogue  in  PLASMA  and  Actl.  ETHER  [Ko-79],  which  is 
also  based  on  the  Actor  model,  has  a  similar  capability. 

8.  PLASMA  and  Actl  are  based  on  a  message  passing  model  of  computation,  but 
they  both  rely  on  other  control  mechanisms  (e.g.,  a  case  statement)  In  addition  to 
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message  passing.  EBL  is  based  on  events  and  uses  them  as  the  only  control 

mechanism 

One  advantage  of  a  message  passing  model  over  a  procedure  based  model  is 
achieved  by  using  continuations  [St-74,  He-76,  Ha-78,  Wa-78a].  Instead  of  waiting  for  the 
result  of  a  procedure,  the  program  unit  replacing  the  procedure  is  supplied  with  an  argument 
specifying  where  to  send  the  result.  The  activator  can  then  relinquish  its  computational 
resources  and  vanish  instead  of  waiting  for  the  result  holding  computational  resources 
[He-76,  Wa-78a].  A  similar  scheme  can  be  used  In  our  event  model  which  therefore  shares 
the  same  advantage  over  the  procedure  based  model.  The  price  paid  fo.  this  early  release 
of  computational  resources  (in  a  message  passing  model  or  in  the  event  model)  is  that  the 
state  of  the  computation  must  be  passed  to  the  continuation,  e.g.,  by  including  it  as 
additional  arguments  to  the  program  unit  replacing  the  procedure  (which  then  passes  it  to 
the  continuation). 

1 .6  Our  Main  Contributions 

The  fundamental  characteristic  or  our  event  model  is  the  ability  of  an  instance  of 
a  program  unit  (an  instance  of  an  event  handler)  to  unilaterally  broadcast  messages  (cause 
events)  without  specifying  their  targets.  The  receivers  (event  handlers)  autonomously 
decide  whether  they  are  interested  in  the  messages  or  not.  The  receivers  can  remove  from 
the  ether,  which  encloses  all  program  units,  one  or  more  messages  in  an  atomic  action. 

In  our  event  model,  the  primitive  objects  (event  objects  or  messages)  are  not 
mutable  objects  since  once  a  message  Is  broadcast  to  the  ether  it  cannot  be  modified.  If  it 
is  a  temporary  message,  it  can  only  be  deleted  and  totally  forgotten;  thus,  it  is  not  viewed 
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as  a  mutable  object.  There  are,  however,  unique  ways  to  model  mutable  objects  in  EBL;  the 
effect  of  mutable  objects  can  be  achieved  due  to: 

1.  The  ability  to  broadcast  permanent  messages  belonging  to  specific  classes 
(cause  multi-use  events),  and  to  read  the  latest  message  from  a  class. 

2.  The  ability  of  program  units  to  remove  messages  from  the  ether  (uncause  or 
forget  single_use  events)  and  to  broadcast  new  messages  from  the  same 
classes. 

The  language  does  not  contain  conventional  constructs  such  as:  variables, 
assignment  statements,  iteration  constructs,  procedures,  functions,  and  semaphores; 
however,  all  these  constructs  can  be  easily  modeled.  The  high  expressive  power  of  the 
language  is  mainly  due  to  our  singla_use  events  which  are  the  work  horse  of  the  language. 

The  implementation  schemes  developed  in  this  thesis  are  not  conventional 
Implementations  of  programming  languages.  The  basic  implementation  scheme  associates  an 
event  class  manager  with  each  event  class,  and  an  event  handler  manager  with  each  event 
handler  in  the  program.  The  managers  communicate  with  each  other  and  operate  without  any 
centralized  control. 

Some  of  the  problems  encountered  during  the  design  of  the  managers  algorithms 
are  reminiscent  of  problems  encountered  in  the  implementation  of  a  distributed  database;  in 
particular,  a  distributed  locking  algorithm.  Our  locking  algorithm  is  a  two  phase  algorithm  in 
which  deadlocks  are  prevented.  In  contrast  to  many  existing  algorithms  which  prevent 
deadlocks  by  defining  a  total  order  on  all  objects  to  be  locked,  our  scheme  only  defines  a 
partial  order  on  all  object  classes.  The  advantage  of  this  scheme  is  that  objects  can  be 
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locked  by  a  requestor  concurrently  and  not  sequentially  as  in  other  algorithms. 

Several  optimization  problems  which  are  of  general  Interest,  e.g.,  optimal 
distribution  of  objects  in  a  network,  have  been  defined  and  investigated.  We  have  proved 
that  the  optimization  problems  and  even  approximations  to  these  optimizations  are  A/P-hard, 
and  suggested  heuristic  algorithms. 

Even  though  the  data  flow  processor  [De-77]  supports  highly  parallel  operation, 
it  was  not  designed  to  support  communicating  sequential  processes.  Several  modifications 
to  the  basic  data  flow  processor  have  been  suggested;  these  increase  the  efficiency  of 
executing  a  program  consisting  of  several  processes  on  the  data  flow  processor.  An 
implementation  of  our  language  on  the  data  flow  processor  adds  to  the  processor  the 
capability  of  procedures  and  synchronization  primitives  such  as  semaphores. 

1 .7  Plan  of  the  Thesis 

The  first  chapter  of  this  thesis  describes  cur  event  model  and  its  relation  to 
message  passing  models.  Our  approach  to  the  language  design  and  to  the  Implementation 
has  been  described.  Chapter  2  gives  a  quite  detailed  overview  of  the  language.  Chapter  3 
Is  intended  to  give  a  deeper  insight  into  the  language.  This  is  done  by  analyzing  some  of  the 
main  properties  of  the  language  more  thoroughly,  and  by  comparison  to  other  languages  and 
models.  Chapter  4  completes  the  definition  of  the  language.  Chapter  6  deals  with  the 
expressive  power  of  the  language.  It  shows  how  conventional  language  constructs  can  be 
expressed  in  the  language.  Chapter  6  gives  some  classical  examples  which  illustrate  the 
ease  of  expressing  various  programs  in  the  language.  These  examples  lead  to  several 
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Chapters  7-9  are  devoted  to  strategies  for  implementation  of  the  language  on 
multiple  processor  systems.  Chapter  7  investigates  implementation  schemes  which  are 
natural  to  the  language.  A  system  with  virtually  unlimited  computational  resources  is 
selected  as  a  concrete  example.  This  system  allows  us  to  abstract  some  of  the  limitations 
posed  by  more  restricted  computer  systems  and  thus  to  concentrate  on  the  fundamental 
problems.  Chapter  8  investigates  the  problems  imposed  by  more  real  processor  networks. 
The  effects  of  limiting  the  number  of  available  processors,  dealing  with  a  processor  network 
of  a  given  configuration  (not  necessarily  a  complete  graph),  and  limiting  the  number  of 
neighbors  of  each  processor,  are  studied.  Chapter  9  examines  the  possibility  of 
Implementing  the  language  on  a  data  flow  processor  [De-77].  The  data  flow  processor  is 
designed  to  achieve  a  highly  parallel  operation  and  is  therefore  a  natural  candidate  for 
implementing  our  language. 

Chapter  1 0  summarizes  the  thesis,  presents  our  conclusions,  and  makes 
suggestions  for  further  research.  Chapter  1 1  contains  the  references.  Appendix  A 
contains  a  formal  definition  of  the  syntax.  Appendix  B  contains  performance  evaluation  of  a 
program  on  a  processor  network,  and  appendix  C  contains  performance  evaluation  of  a 
program  on  a  data  flow  processor. 

Let  i  s  give  some  suggestions  related  to  reading  of  this  dissertation.  A  reader 
who  Is  only  interested  in  the  language  can  read  chapters  2-6.  Appendix  A  can  be  read 
concurrently  with  chapter  4;  it  can  also  be  used  as  a  reference.  A  reader  who  is  primarily 
interested  in  implementation  issues  has  first  to  read  chapter  2,  and  section  4.6.1;  these 
give  sufficient  background  for  understanding  our  implementation  schemes.  Chapter  7  should 
be  read  by  anyone  who  is  interested  in  implementation  schemes  of  the  language.  It  is 
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prerequisite  for  understanding  chapter  9.  Chapter  9  can  be  skipped  by  a  reader  who  is  not 
familiar  with  the  data  flow  processor.  Chapter  8  can  be  read  in  two  different  ways:  An 
implementation  oriented  reader  can  read  it  and  skip  the  proofs;  he  can  view  the  chapter  as 
a  continuation  of  chapter  7.  A  theorist,  however,  who  is  interested  neither  in  the  language 
nor  in  the  implementation  schemes,  can  read  chapter  8  without  first  reading  any  other 
chapter  of  this  thesis.  Performance  evaluation  of  EBL  programs  appears  in  appendixes  B 
and  C.  Appendix  B  can  be  read  after  reading  chapter  8  (without  the  proofs  of  chapter  8). 
Appendix  C  relies  on  appendix  B  and  can  be  read  after  reading  chapter  9. 
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2.  Overview  of  EBL 

This  chapter  contains  a  somewhat  detailed  overview  of  the  language.  The  main 
features  of  the  language  are  described  here  without  the  annoying  little  details. 

2.1  Events  and  Event  Classes 

Event  is  the  main  data  type  of  EBL.  Events  are  abstract  entities  that  are  caused 
during  the  course  of  the  computation.  An  event  is  caused  either  internally  and  explicitly  by 
the  program,  or  externally,  when  some  hardware  device  causes  it.  (In  order  to  avoid 
cumbersome  descriptions,  in  many  places  throughout  the  thesis  the  word  event  stands  for 
an  occurred  event.)  An  event  object  is  created  upon  each  occurrence  of  an  event  and 
carries  some  information  about  the  nature  of  its  occurrence.  This  information  consists  of 
explicit  values,  in  the  form  of  event  parameters,  and  implicit  control  information.  Every  event 
Is  a  member  in  some  event  class,  denoted  by  an  event  class  identifier j  event  class 
Identifiers  are  declared.  All  events  from  an  event  class  are  of  the  same  type,  the  type 
associated  with  the  corresponding  event  class  identifier.  The  number  of  the  parameters  and 
the  types  of  corresponding  parameters  are  Identical  for  all  events  from  the  same  class. 

An  event  parameter  can  be  of  a  simple  type  (e.g.,  int,  bool,  or  char),  or  of  event 
type.  The  value  associated  with  such  parameter  is  either  a  value  of  a  simple  type,  or  an 
event  class  Identifier.  For  example,  If  El  is  an  event  class  Identifier,  then  E1(1)  and  El (2) 
are  examples  of  possible  events  from  class  El.  Events  from  another  class,  E2,  can  be 
E2(E  1,3, true),  and  E2(E1 ,5, false).  The  parameters  of  the  latter  event  are:  the  event  class 


Identifier  El,  the  integer  value  6,  and  the  boolean  value  false. 
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An  event  in  EBl  is  either  cf  a  multl_use  type  (a  multi_use  event),  or  of  a 
single_use  type  (a  single_use  event).  In  the  former  case,  Its  occurrence  is  remembered 
forever,  i.e.,  the  corresponding  event  object  is  permanent.  In  the  latter  case,  its 
occurrence  can  be  forgotten  at  some  stage  of  the  computation,  namely,  the  corresponding 
event  object  is  temporary.  In  both  cases,  the  event  object  created  upon  the  occurrence  of 
the  event  is  an  Immutable  object.  The  main  difference  between  the  two  types  of  events  is 
in  the  number  of  direct  effects  that  they  can  have.  A  direct  effect  of  an  event  is  the 
activation  of  an  instance  of  some  program  unit  (to  be  defined  shortly).  A  multi_use  event 
can  have  several  direct  effects,  while  a  single_use  event  can  have  at  most  one  direct 
effect,  after  which  it  Is  forgotten.  We  say  that  an  event  exists  when  its  object  exists. 

An  orthogonal  property  of  events  is  their  ability  to  recur.  Events  can  be  either 
recurrent  or  non_recurrent.  In  the  former  case  events  can  recur,  in  the  sense  that  at  any 
point  in  time  the  conceptual  list  of  event  objects  from  the  corresponding  event  class,  the 
event  list,  can  contain  identical  objects.  This  list  is  therefore  a  collection  in  the  sense  of 
[He-76];  i.e.,  a  multiset.  In  the  latter  case  events  cannot  recur,  In  the  sense  that  trying  to 
cause  an  event  while  an  Identical  event  is  remembered  has  no  effect.  In  this  case,  at  any 
point  in  time  the  conceptual  list  cannot  contain  Identical  objects,  and  therefore  corresponds 
to  a  set.  The  term  recurrent  stems  from  the  possibility  of  referring  to  several  identical 
events  as  several  instances  of  the  same  event;  however,  the  term  event  instance  will  not 


be  used  here. 
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2.2  Event  Handlers 

A  program  unit  in  EBL  is  called  event  handler.  An  instance  of  an  event  handler  ia 
activated  upon  occurrences  of  events  from  certain  event  classes.  The  event  handler 
consists  of  two  parts:  the  event  handler  heading,  and  the  body.  The  event  handler  heading 
contains  several  event  descriptors  each  of  which  specifies  an  event  class  and  contains 
formal  parameters  (if  the  type  of  the  event  class  contains  parameters),  and  a  where  clause 
which  specifies  a  condition  (a  slightly  extended  conventional  boolean  expression)  that  has 
to  be  satisfied  for  each  activation  of  an  instance  of  the  event  handler.  A  collection  of 
existing  events  that  match  the  event  handler  heading,  namely,  the  collection  contains  one 
event  for  each  event  descriptor  In  the  heading  and  the  condition  is  satisfied,  may  cause  the 
activation  of  an  instance  of  the  event  handler. 

The  body  of  the  event  handler  consists  of  two  parts.-  the  declaration  part  and  the 
script.  The  declaration  part  can  only  contain  declarations  of  special  identifiers  of  type  tag 
(defined  in  section  2.3);  event  class  identifiers  can  be  declared  only  outside  event 
handlers.  The  script  which  defines  the  behavior  of  the  event  handler  has  a  very  limited 
structure;  it  only  contains  a  list  of  events  to  be  caused.  The  following  example  of  an  event 
handler  shows  two  event  descriptors  in  the  event  handler  heading:  sum1(i:  int,  tl:  tag),  and 
sum2(j:  Int,  t2:  tag)  corresponding  to  the  event  class  identifiers  suml  and  sum2 
respectively;  each  contains  two  formal  parameters.  The  heading  also  contains  the 
condition:  i>j.  The  script  specifies  two  events  to  be  caused:  one  from  the  event  class  next, 
and  the  other  from  the  event  class  print. 
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on  suml  (i:  int,  tl:  tag)  a  sum2  (j:  int,  t2:  tag)  where  i>j 
aeq_cause 

next  (1+1)  ; 
print  (i+j) 

end  ; 

An  instance  of  an  event  handler  is  activated  at  most  once  for  every  combination 
of  existing  events  that  match  the  event  handler  heading.  An  event  is  considered  "used" 
after  it  is  selected  for  such  activation.  If  it  is  of  a  single_use  type  it  disappears  after  this 
use  and  therefore  cannot  be  used  for  additional  activations  (this  is  one  of  the  reasons  why 
we  said  "at  most  once",  and  not  just  "once",  at  the  beginning  of  this  paragraph).  If  the 
event  is  of  a  multi_use  type,  it  is  not  affected  by  its  use.  In  order  to  avoid  possible 
ambiguities,  the  activation  of  an  instance  of  an  event  handler  (in  particular,  the  selection  of 
the  events,  and  the  evaluation  of  the  condition  in  the  where  clause)  is  defined  as  an  atomic 
action. 


The  same  event  class  Identifier  can  appear  in  the  headings  of  several  event 
handlers.  Thus,  if  it  is  of  a  multi_use  type,  an  event  from  its  class  can  activate  instances 
of  several  event  handlers.  This  feature  is  discussed  further  in  chapter  3. 

The  execution  of  the  script  of  an  event  handler  involves  causing  the  events 
specified  in  the  script.  These  events  may  refer  to  parameters  of  the  events  that  activated 
this  instance  of  the  event  handler  by  means  of  formal  parameters  in  the  heading  (see  i  and  j 
in  the  example  above).  The  actual  parameters  (which  are  expressions)  of  each  event  in 
the  script  are  evaluated  and  the  event  Is  caused  (an  event  object  is  added  to  the 
corresponding  event  list);  this  is  the  place  where  the  actual  computation  takes  place. 
These  events  can  be  caused  either  sequentially  or  concurrently  (In  parallel)  depending 
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whether  the  body  starts  with  the  keyword  seq_cause,  or  par_cause  respectively;  the 
event  handler  is  a  sequential  handler  or  a  parallel  handler  respectively.  For  each  activated 
Instance  of  the  event  handler  In  the  previous  example,  an  event  from  class  next  Is  caused 
before  an  event  from  class  print.  If  the  event  handler  Is  transformed  to  a  parallel  handler 
then  these  two  events  can  be  caused  In  any  order  or  even  concurrently. 

Let  us  digress  a  tittle  to  examine  why  a  sequential  handler  is  needed  (a  parallel 
handler  simply  allows  expressing  more  parallelism).  The  ability  to  cause  events  sequentially 
is  Important.  One  may  wish  for  example  to  cause  several  events  after  entering  a  critical 
region  and  then  (sequentially)  cause  an  event  Indicating  termination  of  the  execution  of  the 
critical  region.  In  another  example,  one  may  wish  to  print  the  numbers  3  and  6  in  this  order. 
Assuming  printing  a  number  is  triggered  by  causing  an  appropriate  event,  two  events  must 
be  sequentially  cause d  to  achieve  the  desired  effect. 

Since  the  events  caused  by  a  parallel  handler  are  not  ordered,  the  only  way  (or 
slight  modification  of  which)  to  sequentially  cause  events  without  using  a  sequential 
handler.  Is  that  each  event  in  the  sequence  (except  the  last  one)  directly  activates  an 
Instance  of  an  event  handler  which  (directly  or  Indirectly)  causes  the  next  event  in  the 
sequence.  Unfortunately,  such  a  scheme  does  not  work  when  the  events  in  the  sequence 
are  singla_use  events.  If  they  succeed  to  activate  instances  of  the  event  handlers 
needed  to  form  the  sequence,  all  but  the  last  In  the  sequence  cannot  have  any  other  direct 
effect  (by  definition  of  a  single_use  event);  in  particular,  the  effects  originally  expected 
(e.g.,  printing  3).  If  any  of  them  succeeds  to  have  another  direct  effect,  then  the  sequence 
is  broken.  Using  a  scheme  in  which  the  event  handler  whose  instance  should  be  activated 
as  a  direct  effect  of  an  event  in  the  sequence  also  causes  (directly  or  indirectly)  the  next 
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event  In  the  sequence  Is  possible  In  some  cases.  However,  such  a  scheme  is  too 
cumbersome  and  may  result  in  inefficient  programs  in  many  cases.  Thus,  the  need  to  cause 
a  sequence  of  single_use  events  is  the  fundamental  reason  for  the  Inclusion  of  a 
sequential  handler  In  the  language. 

The  condition  in  the  where  clause  of  the  event  handler  heading  contains  a 
conventional  boolean  expression  that  has  access  to  the  formal  parameters  of  the  event 
descriptors  in  the  heading.  It  is  used  to  specify  some  conditions,  or  constraints  on  the 
activating  events.  Special  predicates  for  specifying  additional  constraints  on  the  order  in 
which  events  are  selected  for  activating  instances  of  an  event  handler,  can  be  used  in  the 
where  clause  of  an  event  handler;  they  are  defined  in  chapter  4. 

2.3  Tag  Identifiers 

The  language  also  contains  the  simple  type  tag.  Identifiers  of  type  tag,  tag 
Identifiers,  can  be  declared  outside  event  handlers,  or  within  event  handlers  (as  local 
Identifiers).  The  values  associated  with  Identifiers  of  type  tag  are  obtained  from  a  set  of 

abstract  unique  values:  «e,  ft . called  the  tag  set.  This  is  a  global  set  in  the  sense  that 

there  is  only  one  such  set  for  the  whole  program.  For  each  activation  of  an  instance  of  an 
event  handler  its  local  tag  Identifiers  assume  unique  values  from  the  tag  set.  Once  a  value 
from  the  tag  set  is  associated  with  a  tag  Identifier,  it  is  deleted  from  the  set  and  cannot  be 
associated  with  any  other  tag  identifier. 

Tag  identifiers  can  be  used  to  distinguish  between  the  effects  of  different 
Instances  of  event  handlers.  This  can  be  done  by  tagging  an  event,  namely,  attaching  to  it 
a  parameter  of  type  tag.  This  feature  has  an  important  use  when  trying  to  join  several 
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events  belonging  to  the  same  logical  computation  and  activate  an  event  handler.  It  can  be 
done  simply  by  specifying  In  the  where  clause  of  the  corresponding  event  handler  that  they 
all  have  the  same  tag  (see  example  In  Figure  2.1). 

2.4  Type  Identifiers 

The  language  Is  strongly  typed;  each  Identifier  in  the  program  must  be  declared 
as  being  of  some  type.  In  order  to  make  life  easier  for  the  programmer,  the  definition  of 
type  identifiers  is  allowed.  A  type  Identifier  can  serve  as  a  synonym  or  a  shorthand 
notation  for  an  explicitly  written  type,  or  type  list.  For  example, 
cont  ==  single_use  recurrent  event  (int,  tag)  ; 
defines  cont  as  a  type  Identifier  (not  as  an  event  class  identifier),  and 
record  ==  int,  int,  bool  ; 

defines  record  as  an  identifier  equivalent  to  a  list  of  three  simple  types. 

The  ability  to  define  type  Identifiers  might  seem  just  a  syntactic  sugar;  however, 
as  shown  in  the  next  section,  this  concept  is  needed  for  defining  abstract  data  types  and 
therefore  has  an  important  semantic  role. 

2.6  Modules 

After  the  properties  of  events  and  the  program  units  they  activate  have  been 
described,  the  way  a  program  is  structured  wilt  be  explained.  First,  event  handlers  cannot 
contain  local  event  class  Identifiers  or  other  event  handlers.  However,  the  module  is  a 
mechanism  in  the  language  allowing  the  use  of  local  identifiers. 
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The  module  is  similar  to  that  of  MODULA  [Wi-77b].  This  construct  Is  a  block 
having  two  special  lists  at  its  beginning  (the  module  Interface):  the  import  list,  and  the 
export  list.  The  Import  list  is  a  list  of  Identifiers  declared  outside  the  module  that  should  be 
known  Inside  the  module.  Similarly,  the  export  list  is  a  list  of  identifiers  declared  Inside  the 
module  that  should  be  accessible  outside  the  module.  Thus,  the  module  allows  the  user  to 
have  some  control  on  the  scope  of  identifiers.  A  module  can  contain  other  modules  or  event 
handlers;  however,  event  handlers  cannot  contain  other  event  handlers  or  modules  (their 
only  local  Identifiers  are  the  formal  parameters  and  the  tag  identifiers). 

The  module  provides  some  protection  for  event  class  Identifiers.  If  an  event 
class  identifier  is  declared  in  some  module,  the  only  event  handler  headings  in  which  it  can 
explicitly  appear  are  of  handlers  contained  in  this  module  or  in  Inner  modules  that  import  the 
event  class  identifier.  Only  such  handlers  can  use  events  from  this  class.  However,  all  event 
handlers  whose  script  is  in  the  scope  of  that  event  class  identifier,  in  particular,  handlers 
out  of  the  above  module  that  know  about  the  event  class  Identifier  via  the  exporting  * 
importing  mechanism,  can  explicitly  cause  events  from  its  class. 

An  important  property  of  the  module  is  that  when  a  type  identifier  is  exported, 
only  its  name  is  known  outside  the  module.  The  structure  of  the  denoted  type  is  not  known 
outside  the  module  and  therefore  event  handlers  outside  the  module  cannot  refer  to 
components  of  an  object  from  that  type.  If  such  a  type  is  used  as  the  type  of  a  parameter 
of  an  event  in  some  event  class  then  only  handlers  within  the  exporting  module  can  actually 
break  such  a  parameter  Into  its  constituent  basic  type  components  and  do  some 
computations  on  them.  Formal  parameters  outside  the  module  can  be  bound  to  objects  of 
such  exported  type;  they  can  be  inserted  as  parameters  in  newly  caused  events  (i.e.,  be 
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copied  or  passed  on);  such  formal  parameters  can  be  compared  to  one  another  if  they  are 
of  the  same  exported  type;  but  they  cannot  be  operated  on  outside  the  module  in  other 

ways.  Thus,  the  module  allows  creating  abstract  data  types,  and  encapsulated  program 

* 

units. 

The  module  serves  as  an  interface  between  the  surrounding  environment  and  its 

*  r 

inner  environment.  However,  in  contrast  to  the  event  handler,  the  module  has  no  dynamic 
effect;  Its  only  effects  are  the  establishing  of  rules  for  scope  and  use  of  identifiers.  The 
modules  in  a  program  are  visible  to  the  compiler,  but  they  have  no  effect  at  run  time.  Their 
role  is  different  from  the  blocks  of  ALGOL  which  have  both  static  (local  identifiers)  and 
dynamic  roles. 

2.6  Programs 

A  program  is  a  collection  of  declarations  (of  event  class  identifiers  and  tag 
Identifiers),  of  type  definitions,  of  event  handlers,  and  of  modules  (that  can  contain 
declarations,  type  definitions,  event  handlers,  and  modules,  etc.).  The  execution  of  a 
program  starts  by  the  system  that  causes  an  event  from  the  class  program_start.  This  can 
activate  one  or  more  instances  of  event  handlers,  that  can  cause  other  events,  etc.  All 
those  activities  take  place  concurrently.  At  any  point  In  time  there  are  some  active 
Instances  of  event  handlers  causing  events,  and  there  are  conceptual  lists  of  all  existing 
events  from  each  event  class.  The  program  is  terminated  at  a  point  in  time  at  which  the 
computation  cannot  proceed  and  will  not  be  able  to  proceed  later;  l.e.,  the  following 
conditions  are  satisfied: 

1 .  There  are  no  active  instances  of  any  event  handler. 
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2.  No  instance  of  an  event  handler  can  be  activated  (no  matching  event 
collections). 

3.  No  spontaneously  caused  future  system  events  (defined  in  section  2.8)  will  be 
able  to  activate  any  instance  of  an  event  handler. 

4.  No  event  of  a  class  denoted  by  an  event  class  identifier  explicitly  declared  in 
the  program  (as  opposed  to  a  system  event)  can  (or  will)  be  caused  by  the 
system.  Normally,  If  an  event  class  identifier  E  is  used  as  a  parameter  of  a 
system  event,  events  from  class  E  can  be  caused  by  the  system  (as  opposed  to 
causing  by  an  instance  of  an  event  handler). 

2.7  Event  Relations 

Various  partial  orderings  on  events  and  event  relations  have  been  defined  in 

[Gr-75]  and  [He-77],  and  many  of  the  observations  in  this  section  rely  on  them.  Each  event 

handler  H  defines  a  strict  partial  temporal  ordering  on  the  events  that  activate  an  instance 

of  H  and  those  caused  by  that  instance  of  H.  The  following  two  relations  between  events: 

the  causality  relation  —  c->  ,  and  the  precedes  relation  —  p->  ,  give  a  better  description  of 

the  order  in  which  the  different  activities  in  a  program  take  place.  Foi  a  parallel  handler: 

on  P-j(...)  a  ...  a  Pn(—)  where  B 
par  cause 

Sj  (...); 

v-> 

end  ; 

let  p1 ,  ...  ,  pn  be  a  collection  of  events  that  activates  an  instance  of  the  above  event 
handler,  and  let  Sj,  ...  ,  sm  be  the  events  specified  in  the  script  for  this  instance  of  the 
event  handler;  then  for  each  sj  caused  by  this  instance  of  the  event  handler  (remember 
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that  while  a  non_recurrent  event  exists  an  identical  event  cannot  be  caused),  the 
following  relations  hold: 


Pj  -c->  Sj^  for  all  1  i  I  i  n. 

For  a  sequential  handler: 

on  P  •)(...)  a  ...  a  Pn(...)  where  B 
seq_cause 

S'jt...)  ; 

Sm(...) 

end  ; 


let  p-|,  ...  ,  pn  be  a  collection  of  events  that  act,  'ates  an  instance  of  the  above  event 

handler,  and  let  s-| . sm  be  the  events  specified  in  the  script  fer  this  instance  of  the 

event  handler.  Let  Sj^  be  the  first  event  in  the  latter  list  caused  by  this  instance  of  the 
event  handler,  s ^  the  second,  etc.  and  the  last  one  Sj  where  $  m;  then  the  following 
relations  hold: 


Pj  --c->  Sj^  for  all  1  £  I  <  n,  and  for  all  1  £  k  £  q, 

s.  --p->  Si  for  alii  <  k  <  q-1. 

■«k  ik+1  - 

Another  rule  which  holds  for  any  pair  of  events  p  and  s  Is: 
p  --c->  sop  — p->  s 

This  rule  reflects  the  physical  fact  that  if  one  event  causes  another  one,  then  the  second 
event  must  have  been  preceded  by  the  first  event.  The  above  rules  together  with  the 
following  properties  of  the  relations,  completely  define  the  relations:  both  — c->  and  -- p-> 
are  nonreflexive  transitive  relations. 


By  applying  the  above  rules,  one  can  determine  the  strict  partial  temporal 
ordering  between  the  events  that  activate  an  Instance  of  an  event  handler  and  those 
caused  by  it;  this  ordering  is  simply  equal  to  that  obtained  by  the  precedes  relation.  In 
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general  however,  a  strict  partial  ordering  among  all  events  caused  by  a  program  cannot  be 

determined  even  if  they  are  known.  The  reason  is  the  nondeterministic  nature  of  our  model: 

the  semantics  of  the  language  does  not  define  the  order  of  (or  the  algorithm  for)  choosing 

the  next  event  handier  to  be  activated.  In  cases  of  event  class  identifiers  of  a  single_use 

type  appearing  in  more  than  one  event  handler,  an  arbitrary  choice  is  made  and  this  implies 

that  several  strict  partial  orderings  on  the  events  caused  by  the  program  are  possible.  For 

example,  consider  the  following  program: 

El,  E2,  E3:  single_use  recurrent  event  ; 

on  program_start 
seq_cause  El 
end  ; 

on  El 

seq_cause  E2  ;  E3 
end  ; 

on  El 

*eq_cause  E3  ;  E2 
end  ; 

In  this  program,  one  event  is  caused  from  each  of  the  classes  El,  E2,  and  E3;  let  el,  e2, 
and  e3  be  these  events  respectively.  One  cannot  determine  whether  e2  precedes  e3  or 
e3  precedes  e2  even  though  the  fact  that  both  occur  is  known.  Simply  saying  that  e2  and 
e3  are  not  ordered  is  not  correct  since  this  allows  the  possibility  that  they  are  caused  in 
parallel.  However,  events  caused  by  an  Instance  of  a  sequential  handler  cannot  be  caused 
in  parallel;  they  must  be  ordered  by  the  precedes  relation.  Thus,  two  strict  partial  orderings 
are  possible  in  this  example. 

Frequently,  in  specifying  the  behavior  of  a  program  or  a  subprogram,  the 
occurrence  order  of  some  collection  of  events  (e.g.,  all  events  in  a  certain  event  class)  is 
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referred  to.  This  order  reflects  the  total  temporal  ordering  on  the  events  under  discussion.  It 
is  consistent  with  the  transitive  closure  of  the  precedes  relation  defined  above. 

2.8  System  Events 

So  far  r.o  way  of  interacting  with  the  external  world  has  been  described.  In  fact, 
the  language  does  not  contain  specific  constructs  for  this  aim.  In  each  implementation  of 
the  language,  some  system  event  class  identifiers  will  be  defined  for  interacting  with  the 
standard  I/O  devices,  with  the  special  devices  to  be  controlled,  and  in  general  with  the 
operating  system.  The  following  is  an  example  of  a  system  event  class  identifier: 
print:  single_use  recurrent  event  (int) 

The  semantics  of  such  system  event  class  identifier  can  be  that  the  system  prints  the 
parameters  of  all  events  from  the  class  print,  according  to  their  occurrence  order. 

2.9  Example 

Figure  2.1  contains  an  example  that  illustrates  some  of  the  features  of  the 
language.  The  purpose  of  the  example  is  not  to  demonstrate  how  programming  in  EBL  is 
convenient,  but  rather,  to  incorporate  many  of  the  language  features  in  one  example. 
Examples  demonstrating  the  ease  of  expressing  various  programs  are  given  in  chapter  6. 
The  example  describes  a  subprogram  for  computing  concurrently  factorial(i)  and  fuctorial(j). 
When  both  results  are  ready  their  sum  is  printed.  This  subprogram  can  be  activated 
concurrently  any  number  of  times.  The  subprogram  consists  of  two  modules:  one  for 
computing  factorial  in  an  iterative  manner,  and  another  that  uses  the  first  one  and  prints  the 
desired  result;  it  is  activated  by  causing  an  event  of  the  form:  sum_f(i,  j).  We  assume  that 
the  system  event  class  identifier  print,  described  earlier,  exists  in  the  implementation  of  the 
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language.  Note  that  the  braces  {...}  are  used  to  indicate  the  beginning  and  the  end  of  a 
comment. 

cont  ==  single_use  recurrent  event  (int,  tag)  ;  {  type  definition  } 

module  {  factorial  sun.  } 
export:  sum_f  : 
import:  cont,  print  ; 

sum_f:  single_use  recurrent  event  (int,  Int)  ; 
suml ,  sum2:  cont  ; 

module  {  factorial  } 

export:  F  ;  {  F  can  only  be  caused  outside  the  module  } 

import:  cont  ;  {  the  structure  of  cont  is  known  here  } 

F:  single_use  recurrent  event  (int,  int,  cont,  tag)  ;  {  declaration  } 

on  F  (n,  p:  int,  c:  cont,  t:  tag)  where  n<=1 

par_cause  c(p,  t)  {  cause  the  continuation  event  } 

end  i 

on  F  (n,  p:  int,  c:  cont,  t:  tag)  where  n>1 

par_cause  F  (n-1,  n*p,  c,  t)  {iterate} 

and  ; 

end  ;  {  of  factorial  module  } 

on  sum_f  (I,  j:  int)  {  when  factorial  sum  is  requested  } 

t:  tag  ; 

par_cause  {  activate  the  factorial  module  twice  with  same  tag  } 

F  (i,  1,  suml,  t)  ;  F  (j,  1,  sum2,  t)  {  concurrently  } 

end  ; 

{  when  two  matching  results  of  factorial  arrive  print  cum  } 
on  suml  (i:  int,  tl:  tag)  a  sum 2  (j:  int,  t2:  tag)  where  t1=t2 
par_cause  print  (i+J) 

end  ; 

end  ;  {  of  factorial  sum  module  } 

Figure  2.1  Factorial  sum 


Several  observations  can  be  made  about  the  example  In  Figure  2.1 : 

1 .  The  loop  is  implemented  by  causing  F  within  one  of  the  event  handlers  activated 
by  F.  This  is  reminiscent  of  a  recursive  procedure  call;  nevertheless,  no  state  of 
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the  computation  needs  to  be  saved  as  a  result  of  this  Inner  cause;  the  analogy  to 
tail  recursion  is  appropriate. 

2.  Tags  are  used  to  join  results  of  matching  subcomputations. 

3.  Note  the  modularity  of  the  program.  F  can  be  caused  outside  the  inner  module  in 
which  it  has  been  declared  but  it  cannot  be  used  (in  the  sense  of  section  2.2) 
there.  F  is  unknown  outside  the  outer  module  since  it  does  not  appear  in  the 
export  list  of  that  module. 

4.  The  factorial  module  is  used  in  a  modular  manner.  In  order  to  Invoice  the 
computation  of  factorial(n)  one  has  simply  to  cause  an  event  of  the  form 
F(n,1,C,t)  and  to  wait  for  the  result  event  in  another  event  handler.  The  result 
event  has  the  form  C(r,t)  where  r=factorlel(n)  if  n>0,  else  1 .  One  does  not  have 
to  know  how  the  factorial  module  Is  Implemented. 

6.  suml  and  sum  2  are  used  as  continuations. 

6.  The  type  identifier  cont  is  known  in  both  modules  since  It  has  been  Imported 

appropriately.  Its  structural  details  are  also  known  in  both  modules  since  they 
are  inner  modules  in  the  environment  in  which  cont  has  been  defined. 

Suppose  the  two  events,  sum_f(1,3)  and  sum_f(2,1),  are  caused  sequentially. 
The  corresponding  strict  partial  temporal  ordering  between  the  caused  events  is  depicted  in 
Figure  2.2  (simitar  drawings  appear  in  [He-77]).  From  the  graph  in  Figure  2.2  it  can  be  seen 
how  four  activities  take  place  concurrently,  and  how  the  results  of  related  activities  are 
Joined.  Unordered  events  (e.g.,  prlnt(3)  and  print(7»  can  occur  in  any  order  or  concurrently. 
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Figure  2.2  Events  ordering 


2.10  Fairness 

In  order  to  analyze  or  prove  (even  Informally)  properties  of  a  program  written  In 
some  conventional  sequential  programming  language  one  normally  makes  an  Implicit  positive 
speed  assumption.  In  a  statement  oriented  language  the  assumption  Is  that  statements  are 
executed  in  a  positive  speed.  More  generally,  the  assumption  is  that  if  a  point  In  the 
sequence  of  steps  executed  by  a  program  Is  reached,  then  the  next  step  will  eventually  be 
executed  (if  its  execution  is  permitted  by  the  program).  More  specific  assumptions  can  be 
made  if  more  information  is  known  about  the  implementation;  but  such  information  is  not 
provided  by  the  definition  of  a  language. 

In  a  language  for  parallel  programming  the  notion  of  a  sequence  of  steps  is  not 
directly  applicable.  However,  assumptions  which  are  analogous  to  tne  positive  speed 
assumption  should  also  be  made  for  analyzing  or  proving  properties  of  programs.  In  a 
process  based  model  each  process  Is  generally  viewed  as  a  sequence  of  steps.  The 
corresponding  assumption  Is  that  each  process  Is  executed  In  a  positive  speed.  In  addition 
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to  the  nondeterminism  which  is  inherent  to  languages  for  parallel  programming,  the 
corresponding  models  can  also  be  nondeterminate.  In  such  cases,  it  may  be  more  difficult  to 
express  the  analogue  to  the  positive  speed  assumption.  Our  model  belongs  to  this  latter 
category. 


This  discussion  leads  to  the  problem  of  fairness  of  an  Implementation  of  a 
language.  If  a  language  definition  does  not  contain  some  fairness  rules  which  must  be  met 
by  every  implementation  of  the  language  one  may  not  be  able  to  analyze  or  prove  properties 
of  a  program  which  are  Implementation  independent.  In  general,  only  weak  fairness  rules 
should  be  included  in  a  language  definition  in  order  not  to  constrain  too  much 
Implementations  of  the  language.  An  example  of  a  weak  fairness  rule  is:  if  a  computational 
activity  can  proceed  it  eventually  proceeds. 

Definitions  of  most  existing  languages  do  not  include  fairness  rules;  although 
limited  rules  for  several  constructs  may  exist.  As  an  example,  suppose  one  writes  a 
program  in  which  two  processes  P.j  P2  are  activated.  Each  process  consists  of  a 
nonterminating  loop.  In  each  cycle  process  Pj  prints  some  number  on  printer  I.  If  such  a 
program  Is  written  in  languages  such  as:  PL/1,  CONCURRENT  PASCAL  [BH-76],  MODULA 
[Wi-77b],  or  communicating  sequential  processes  [Ho-78a];  nothing  guarantees  the 
programmer  that  process  P^  (P2)  will  print  even  one  number.  Our  language  defers  from 
other  languages  in  that  fairness  rules  are  part  of  its  definition.  Using  these  rules  one  can 
easily  show  that  infinitely  many  numbers  are  printed  on  each  printer.  Actl  [He-79] 
manifests  a  similar  property  by  its  guarantee  of  service. 
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This  section  gives  some  rules  about  the  way  a  computation  proceeds  in  our 
model.  These  ruies  are  quite  relaxed  in  order  not  to  constrain  too  much  Implementations  of 
the  language.  The  rules  try  to  guarantee  two  separate  requirements.  First,  that  the 
computation  will  eventually  proceed  if  possible.  Second,  that  some  fairness  is  provided. 
Formal  treatment  of  the  fairness  problem,  based  on  temporal  logic,  appears  in  [Pn-79].  It  is 
true  that  the  language  contains  predicates  which  allow  the  user  to  have  some  explicit 
control  over  the  fairness  of  the  execution.  However,  in  our  opinion  the  language  should 
guarantee  at  least  a  minimal  fairness  even  if  the  user  does  not  use  the  predicates. 
Fairness  is  normally  discussed  in  the  context  of  concurrent  processes  competing  for 
resources.  Our  model  is  different  from  a  process  based  model  therefore  the  notion  of 
fairness  is  different  in  the  context  of  EBL.  The  fairness  rules  discussed  later  In  this  section 
explicate  our  notion  of  fairness. 

One  must  observe  that  the  fairness  rules  do  not  rule  out  the  possibility  of 
starvation  from  every  program.  Suppose,  for  example,  the  heading  of  event  handler  H  is: 

on  Ei  a  E2 

where  E-j  and  E2  are  single_use  event  class  identifiers  that  also  appear  in  the  event 
descriptor  lists  of  other  event  handlers.  The  fairness  rules  do  not  rule  out  the  possibility 
that  no  instance  of  H  will  ever  be  activated  even  though  infinitely  many  times  a  pair  of 
events  (one  from  each  of  the  event  classes  E-j  and  E2)  exists.  The  fairness  rules 
guarantee,  however,  that  the  scheme  for  expressing  a  P  operation  on  a  semaphore  variable 
(see  chapter  5)  is  fair  (in  the  sense  that  if  enough  V  operations  are  executed  then  every  P 
operation  eventually  terminates). 
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The  first  fairness  rule  is: 

F0.  Once  an  instance  of  an  event  handler  is  activated,  execution  of  its  script 
eventually  terminates. 

In  fact,  FO  should  be  conditioned  on  availability  of  enough  computational  resources.  We  shall 
assume  that  such  qualifications  are  added  to  all  our  fairness  rules.  The  motivation  for  FO  is 
that  causing  each  event  in  the  script  of  an  event  handler  can  be  executed  in  finite  time, 
and  the  number  of  events  specified  by  the  script  of  an  event  handler  Is  fixed.  Thus,  the 
execution  of  the  script  can  be  completed  in  finite  time. 

FO  Is  not  sufficient  since  an  implementation  of  the  language  may  choose  not  to 
activate  any  event  handler  Instance  at  all.  Such  an  implementation  does  not  violate  FO  but 
is  certainly  unacceptable.  Before  presenting  the  next  rules  we  define  several  conditions 
which  may  be  satisfied  by  a  program.  These  conditions  are  then  used  in  the  rules 
themselves. 

Let  e(  be  an  event  from  class  E(  which  exists  at  time  tQ.  Let  H  be  an  event 
handler.  Assume  C  is  a  clock  ticking  at  some  fixed  positive  finite  rate;  the  time  interval 
defined  by  two  adjacent  ticks  is  the  clock's  period.  The  various  conditions  and  rules  are 
defined  next. 

Cl.  If  e|  is  not  used  at  any  time  t>t0,  then  infinitely  many  periods  following  t^  contain 
points  in  time  at  which  e^  can  be  a  member  of  at  least  one  event  collection  which 
couid  activate  an  instance  of  some  event  handler. 

C 2.  Ej  is  of  a  mutti_use  type.  If  e(  is  not  used  by  instances  of  H  at  any  time  t^t^ 
then  infinitely  many  periods  following  tQ  contain  points  in  time  at  which  e(  can  be 
a  member  of  at  least  one  event  collection  which  could  activate  an  instance  of  H. 
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C3.  The  event  descriptor  1st  of  H  contains  only  awtti_iise  event  class  identifiers; 
there  are  a  event  descriptors,  and  the  correspondtog  event  class  identifiers  are 
Ef, ... ,  Eg|.  ec={e1, ... ,  e—}  is  an  event  coMection  associated  with  the  above 
event  class  identifiers,  if  ec  does  not  activate  an  instance  of  H  at  any  time  Ot^ 
then  infinitely  suuiy  periods  folowtog  ^  contain  points  in  time  at  which  ec  could 
activate  an  instance  of  H. 

Several  fairness  rules  can  be  defined  based  on  the  previous  condttions. 

FI.  For  ale^tglf  condttion  Cl  is  satisfied  then  eventualy  e{  is  used  at  thae  Qt^ 
Ride  FI  guarantees  that  processing  of  a  request  (represented  by  e()  which  can  be  handed 
by  one  event  handter  or  by  several  event  handers  eventualy  begins. 

F2.  For  aW  ej,  H,  ^  if  condttion  C2  is  satisfied  then  eventually  e}  is  used  by  an 
instance  of  H  at  tone  Otg. 

Rule  F2  guarantees  that  a  Message  (represented  by  et)  broadcast  to  several  event 
handers  is  eventualy  received  by  al  of  them. 

F3.  For  al  ec={e|, ... ,  e^},  H,  ^  if  condition  C3  is  satisfied  then  eventualy  ec 
activates  an  instance  of  H  at  tlwe  Ot,,. 

Let  fj(t)  be  a  colection  of  existing  events  frost  event  class  Ej  at  tsae  t  for  hi, ... ,  m. 
Suppose  one  wants  to  perform  some  computation  on  each  element  ec  in  the  cartesian 
product  F(t)sf  |(t)  x  ...  x  £n(t)  which  is  budt  as  tiara  progresses.  Rule  F3  guarantees  that  if 
ecn£(t0)  then  the  computation  correspondtog  to  ec  eventualy  begins  (possMy  before  t^. 
In  other  words,  F3  guarantees  that  conduits  [Wa-78a]  can  be  correctly  implemented  to  EBL 
(without  using  EBL's  predicates). 
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Ail  the  fairness  rules  have  the  form:  if  some  condition  is  satisfied  then  eventually 
S  (something)  occurs.  This  is  a  very  relaxed  form  and  an  implementation  of  the  language 
should  try  not  to  delay  unreasonably  the  occurrence  of  S.  However,  we  do  not  include  the 
additional  requirement  in  the  definition  of  the  language. 

2.11  Summary 

An  overview  of  EBL  has  been  presented  in  this  chapter.  The  language  is  based  on 
events  which  provide  the  only  control  mechanism.  Events  are  explicitly  caused  by  the 
program  and  they  activate  Instances  of  (dynamic)  program  units  called  event  handlers.  The 
only  operation  that  can  be  performed  by  an  instance  of  an  event  handler  is  the  causing  of 
new  events  (which  can  activate  more  instances  of  event  handlers).  Many  event  handler 
instances  can  be  executed  concurrently.  In  contrast  to  event  handlers,  modules  have  only 
static  effects;  they  have  no  effect  at  run  time.  Several  fairness  rules  are  part  of  the 
language  definition;  they  must  be  met  by  every  implementation  of  EBL. 

A  deeper  insight  Into  the  language  Is  given  in  chapter  3.  The  definition  of  the 
language  is  completed  in  chapter  4. 
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3.  Relation  to  Other  Mechanisms 

The  purpose  of  this  chapter  is  to  give  a  deeper  insight  into  the  language  before 
diving  in  the  next  chapter  Into  the  detailed  definition  of  the  language.  It  starts  with  a 
comparison  of  certain  features  of  our  event  model  with  other  models  (process  based  models, 
and  message  passing  models);  continues  with  an  analysis  of  different  kinds  of  modularity  in 
the  language;  discusses  possibilities  for  parallelism  in  the  language;  proceeds  with  a 
discussion  of  synchronization  capabilities  in  the  language;  and  then  shows  the  relation 
between  the  language  and  some  other  models  of  computation. 

3.1  Relation  to  Other  Models 

This  section  examines  why  event  semantics  seem  promising  as  the  underlying 
basis  for  a  parallel  programming  ianguage  for  distributed  systems.  This  is  done  by 
comparison  to  other  models:  message  passing  models  such  as  the  Actor  model  [He-76]  and 
the  mu  calculus  [Ha-78,  Wa-78a],  MODULA  [Wi-77b]  an  example  of  a  process  based  model, 
and  procedure  based  models  such  as  ALGOL  [Na-63]. 

The  message  passing  models  and  the  event  model  on  one  hand,  and  MODULA  on 
the  other  hand,  are  all  intended  to  allow  expressing  concurrent  computations.  In  the  first 
cases,  each  activity  can  unilaterally  spawn  new  activities,  thus  forming  a  multilevel  tree  of 
concurrent  activities.  In  the  latter  case,  the  computation  Is  restricte  1  to  cooperating 
sequential  processes,  only  one  of  which  (the  main  program)  can  create  new  processes.  In 
order  to  achieve  a  multilevel  tree  of  concurrent  activities,  whenever  a  secondary  process 
(not  the  main  program)  wishes  to  create  a  subprocess  it  has  to  request  it  from  the  main 
program.  The  communication  with  the  main  program  is  needed  In  general  since  a  process 
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decision  to  spawn  new  subprocesses  may  be  data  dependent.  Observe,  however,  that  the 
above  limitation  of  MODULA  is  not  inherent  to  every  process  based  model;  PL/l  for  example, 
does  not  suffer  from  such  limitations. 

The  disadvantages  in  the  case  of  MODULA  are  additional  communication  overhead, 
and  the  bottleneck  created  by  the  need  to  communicate  with  one  process.  For  example, 
the  time  required  to  Initiate  N=2n-2  activities,  whose  causality  relation  has  the  form  of  a 
constant  depth  (n-1)  rooted  complete  binary  tree,  can  be  proportional  to  the  height  of  the 
tree  n-1  (i.e.,  O(log  N))  in  the  case  of  the  message  passing  models  and  the  event  model 
(assuming  at  least  N  free  processors),  but  must  be  at  least  proportional  to  the  number  of 
nodes  in  the  tree  (except  the  root)  2n-2  (I.e.,  O(N))  in  the  case  of  MODULA.  Thus,  the 
event  model  shares  an  advantage  with  the  message  passing  models  over  MODULA  in  that 
they  both  allow  spawning  of  new  activities  at  a  higher  rate,  therefore  expressing  a  higher 
degree  of  concurrency  within  a  computation. 

Let  us  describe  the  basic  computational  steps  of  several  models  in  message 
passing  terms.  In  a  procedure  based  model,  a  procedure  call  involves  the  activation  of  a 
procedure  and  the  subsequent  return  of  a  value.  This  can  be  viewed  as  passing  a  message 
from  the  activator  to  the  procedure,  followed  by  passing  a  message  from  the  procedure  to 
the  activator.  In  this  case,  the  basic  computational  step  consists  of  two  interactions,  each 
Involving  two  instances  of  program  units.  In  a  message  passing  model  the  basic 
computational  step  is  simpler;  It  only  includes  the  passing  of  a  message  from  one  instance  of 
a  program  unit  to  another  one.  Here,  there  is  one  Interaction  between  two  instances  of 
program  units.  In  our  event  model,  the  basic  computational  step  is  even  simpler;  it  only 
includes  the  sending  of  the  message.  Here,  only  one  Instance  of  a  program  unit  Is  involved 


Relation  to  Other  Models 


-  49  - 


Section  3.1 


and  the  interaction  is  between  it  and  the  ether  (or  between  it  and  the  system). 

Let  us  examine  how  a  computation  consisting  of  several  nested  subcomputations 
(at  levels  1,  ...  ,  n)  progresses  In  several  models.  In  a  procedure  based  model,  the 
computation  terminates  when  all  the  subcomputations  at  levels  1,  ...  ,  n  terminate.  In  a 
message  passing  model,  starting  a  subcomputation  corresponds  to  passing  a  message  to  an 
Instance  of  a  program  unit.  The  passing  of  the  original  message  causes  passing  of 
messages  activating  the  subcomputations  of  level  1 .  The  processing  of  the  original  message 
terminates  (conceptually)  when  the  messages  activating  the  subcomputations  of  level  1  are 
received  by  their  targets  (and  not  when  all  the  nested  messages  are  processed). 

In  the  event  model,  starting  a  subcomputation  is  achieved  by  causing  an  event. 
In  the  processing  of  the  original  event,  new  events  for  activating  the  subcomputations  of 
level  1  are  caused.  The  processing  of  the  original  event  terminates  when  the  messages 
activating  the  subcomputations  of  level  1  are  sent  (broadcast);  i.e.,  possibly  prior  to  the 
association  of  messages  with  their  receivers. 

Thus,  in  the  event  model  an  instance  of  a  program  unit  can  vanish,  relinquishing 
computational  resources,  as  soon  as  Its  messages  are  sent  and  before  the  possible 
receivers  observe  them.  The  price  for  this  early  release  of  computational  resources  in  the 
event  model  is  paid  by  the  receivers  which  have  to  check  whether  they  are  interested  in 
the  messages  or  not.  The  semantics  of  our  language  restricts  the  required  checking  (by  the 
use  of  event  classes):  a  program  unit  need  not  check  all  messages  but  only  those  from 
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Suppose  one  wants  to  perform  some  computation  on  each  element  in  the 
cartesian  product  S^  x  ...  x  S^.  Further,  suppose  each  element  of  S|  is  represented  by  a 
message  (event)  in  the  class  associated  with  Sj.  In  our  model,  an  instance  of  a  program  unit 
can  specify  that  any  collection  of  k  messages  (events),  each  from  a  specific  class, 
activates  an  instance  of  the  program  unit.  If  n  messages  are  broadcast  from  each  of  the  k 
classes,  totally  k*n  messages,  n*1  instances  of  the  program  unit  are  activated,  one  for  each 
combination  of  k  messages  from  those  classes.  In  the  Actor  model,  each  message 
activates  one  instance  of  a  program  unit,  thus  in  order  to  achieve  the  same  effect  at  least 
nk  messages  are  needed.  In  addition  to  the  higher  number  of  required  messages,  the 
programmer  has  to  explicitly  write  an  appropriate  algorithm  in  the  Actor  model,  in  contrast  to 
our  model.  The  conduits  of  the  mu  calculus  [Wa-78a]  allow  expressing  the  above  behavior 
easily;  however,  the  number  of  messages  sent  Is  at  least  k*n+nk.  (Equality  can  be  reached 
by  extending  the  conduit  construct  to  handle  k  classes  of  messages,  and  not  only  two 
classes  as  defined  In  [Wa-78a].)  Note  that  the  smaller  number  of  messages  required  in  our 
model  to  activate  nk  instances  of  th«  program  unit  Is  only  a  matter  of  level  of  abstraction. 
At  a  lower  level  of  abstraction  (the  language  Implementation  level)  some  signal  is  needed  to 
trigger  the  activation  of  each  instance  of  the  program  unit. 

The  ability  of  an  event  object  to  carry  event  class  identifiers  as  parameters 
provides  for  a  special  programming  style  which  has  lately  become  popular,  the  use  of 
continuations  [St-74,  He-76,  Ha-78,  Wa-78a].  An  event  handler  can  be  passed  a 
parameter  which  specifies  what  to  cause  when  done,  namely,  instances  of  which  event 
handlers  to  activate  next.  Continuations  are  used  in  several  places  in  this  thesis;  some  of 
them  are:  the  factorial  module  in  the  example  In  chapter  2,  the  impfementation  scheme  for 
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procedures  (see  chapter  5),  and  the  airline  reservation  system  (see  chapter  6). 

Various  message  passing  schemes  can  be  built  on  top  of  EBL.  The  fact  that  an 
event  has  parameters  associated  with  it  allows  it  to  behave  as  a  message  carrier ;  in 
addition  to  the  activation  of  some  processes,  the  event  delivers  them  the  carried  message. 
By  using  multi_use  events,  broadcast  modes  can  be  implemented,  since  causing  an  event 
actually  broadcasts  some  message,  the  event  object,  "To  Whom  It  May  Concern". 

The  event  model  allows  broadcasting  a  message  that  can  be  received  by  any 
(one)  program  unit  which  finds  it  interesting  out  of  a  group  of  n  program  units;  leaving  the 
task  of  selecting  the  program  unit  to  the  system,  when  more  than  one  program  unit  is 
interested  in  the  message.  In  order  to  achieve  the  same  effect  in  the  Actor  model  the 
programmer  has  to  devise  an  appropriate  algorithm.  The  same  algorithm  to  be  used  for  the 
implementation  of  our  language  can  be  employed  for  this  purpose.  The  identity  of  the  n 
program  units  must  be  known  to  the  algorithm  in  case  of  the  Actor  model,  whereas  no  such 
requirement  exists  in  our  model. 

The  ability  of  an  instance  of  a  program  unit  in  the  event  model  to  broadcast  a 
message  to  several  program  units  has  no  analogue  in  the  Actor  model  or  in  the  mu  calculus. 
So  is  the  ability  to  broadcast  a  message  without  knowing  what  program  units  will  receive  it, 
how  many  instances  of  program  units  will  receive  it,  and  when  will  it  be  received.  As  a 
special  case,  the  event  model  allows  passing  a  message  to  one  instance  of  a  program  unit, 
as  is  done  in  the  above  models.  Pattern  directed  invocation  languages  such  as  ETHER 
[Ko-79]  manifest  such  capabilities;  the  relation  to  our  model  is  investigated  in  section  3.7. 
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mechanism  (for  this  purpose)  in  programming  languages  is  the  use  of  variables  and 
assignment  statement;  this  is  obviously  a  destructive  mechanism.  A  similar  concept  in  the 
context  of  message  passing  is  the  cell  [Gr-75]  which  is  used  in  the  Actor  model;  this  is  also 
a  destructive  mechanism.  As  was  pointed  out  in  [Ha-78],  the  use  of  cells  should  be  avoided 
whenever  possible  since  it  complicates  the  semantics  of  a  language.  Cells,  however,  (and 
destructive  mechanisms,  in  general)  save  space  by  destroying  past  information.  The  mu 
calculus  incorporates  the  conduit  construct  [Wa-78a]  which  only  allows  a  confined  kind  of 
mutability.  It  is  a  compromise  between  allowing  and  forbidding  the  use  of  mutable  objects; 
this  is  an  additive  mechanism. 

In  EBL  there  are  no  mutable  objects;  therefore,  in  light  of  the  above  discussion, 
this  could  limit  the  expressive  power  of  the  language.  However,  the  effect  of  mutable 
objects  Cd.i  be  achieved  due  to: 

1.  The  ability  to  create  permanent  objects  belonging  to  specific  classes  (cause 
multi_use  events),  and  to  read  the  latest  object  from  an  event  class;  this  is  an 
additive  mechanism.  This  approach  is  pursued  in  the  readers  writers  example  in 
chapter  6. 

2.  The  ability  of  a  program  unit  to  delete  several  temporary  objects  belonging  to 
specific  classes  (use  single_use  events),  and  to  create  new  objects  from  the 
same  classes;  this  is  a  destructive  mechanism.  This  approach  is  pursued  in 
chapter  5.  This  ability  adds  to  the  expressive  power  of  the  language  but  also 


complicates  its  semantics. 
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3.3  Modularity  Issues 

Modularity  is  manifested  in  several  forms  in  the  language;  we  use  the  same  name 
In  discussing  all  of  them.  The  first  source  of  modularity  stems  from  the  semantics  of 
modules.  The  mechanism  of  exporting  -  importing  of  identifiers  provides  for  hiding  and 
sharing  of  identifiers  between  program  units  in  a  controlled  way.  For  example,  in  Figure  2.1 
F  is  known  in  both  modules  but  not  outside  the  outer  module.  Modules  protect  event  class 
identifiers  against  undesired  uses  (in  the  sense  of  section  2.2).  This  protection  is 
especially  important  in  the  case  of  single_use  events,  which  may  vanish  if  an  unauthorized 
event  handler  uses  them.  For  example,  in  Figure  2.1  F  is  protected  by  the  factorial  module; 
similarly,  sum_f  is  protected  by  the  factorial  sum  module. 

Modules  allow  creating  encapsulated  program  units  and  abstract  data  types.  One 
can  write  a  module,  specify  its  behavior  in  terms  of  the  relation  between  events  it  uses  and 
events  it  causes,  and  then  use  it  without  paying  attention  to  the  way  it  is  implemented;  i.e., 
in  a  bottom  up  manner.  For  example,  in  Figure  2.1  one  can  begin  by  writing  the  factorial 
module.  The  behavior  of  this  module  can  be  specified  as  follows:  Each  event  of  the  form 
F(n,1,C,t)  causes  an  event  of  the  form  C(r,t)  where  r=factorlal(n)  if  n>0,  else  1.  When  this 
module  is  then  used  one  does  not  have  to  know  whether  factorial  is  computed  iteratively, 
recursively,  or  by  table  lookup.  Similarly,  the  behavior  of  the  factorial  sum  module  can  be 
specified  as  follows:  each  event  of  the  form  sum_f(i,J)  causes  an  event  of  the  form  prlnt(k); 
k=factorial(i)+factorial(J)  where  factorial(n)  Is  1  if  n<0. 

The  above  properties  of  modules  are  also  rasirable  lor  a  top  down  design  of  a 
program.  Like  in  other  languages,  a  program  can  be  designed  by  step-wise  refinements 


Modularity  Issues 


-  55  - 


Section  3.3 


[Di-72].  At  each  step  a  module  contains  only  trivial  event  handlers  that  activate  inner,  still 
non-existing,  event  handlers  and  returns  (causes)  the  correct  result  events  when  the  inner 
event  handlers  return  (cause)  their  result  events.  The  next  refinement  consists  of  defining 
inner  modules,  in  which  inner  event  handlers  implement  the  desired  behavior  of  the  previous 
step,  again  to  a  certain  level  of  abstraction.  This  process  continues  until  the  innermost 
event  handlers  which  actually  perform  the  necessary  computation  are  written. 

As  an  example  consider  the  factorial  sum  problem  of  chapter  2.  Suppose  the 
activating  event  is  sum_fact  (instead  of  sum_f).  In  the  first  step,  the  program  can  consist 
of  the  following  module: 

module 

export:  sum_fact  ; 

import:  print  ; 

sum_fact:  event  (int,  int)  ; 

sum_ready:  event  (Int)  ; 

on  sum_fact  (i,  j:  int) 

par__cause  sum_f  (l,  J) 

end  ; 

on  sum_ready  (i:  int) 

par^caute  print  (i) 

end  ; 

end  ; 

In  the  second  refinement  the  subprogram  of  Figure  2.1  except  the  factorial  module  can  be 
added  within  the  above  module;  print(i+j)  is  replaced  by  sum_ready(l+j),  and  sum_ready  is 
added  to  the  import  list.  The  last  refinement  involves  writing  the  factorial  module  within  the 
factorial  sum  module. 

If  programs  are  written  in  the  way  described  above  the  intermediate  steps  need 
not  be  deleted  from  the  program  at  each  refinement  step;  they  can  remain  there.  A  clever 
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compiler  can  eliminate  from  the  program  the  causing  of  intermediate  events  which  constitute 
the  hand-shaking  between  event  handlers  of  nested  modules,  and  thus  the  efficiency  of  a 
program  is  not  affected  by  the  top  down  design.  An  obvious  advantage  of  this  approach  is 
that  alt  the  design  steps  remain  in  the  final  program  text.  The  text  may  be  longer  than  the 
one  obtained  if  intermediate  steps  are  deleted.  However,  the  program  is  easier  to 
understand  and  maintain  since  it  is  hierarchically  built. 

Another  kind  of  modularity  Is  provided  by  the  language  (a  similar  property  is 
described  in  [Ko-76]).  It  stems  from  several  reasons.  First,  the  order  of  event  handlers  or 
modules  within  the  module  containing  them,  or  within  the  program  (if  they  are  not  contained 
in  any  module),  has  no  effect  on  the  meaning  of  the  program.  Second,  an  event  class 
identifier  can  appear  In  the  headings  of  more  than  one  event  handler.  If  an  event  from  such 
an  event  class  is  of  a  single_use  type  it  activates  at  most  one  event  handler  instance;  If  it 
is  of  a  multi_use  type  it  may  activate  instances  of  more  than  one  event  handler.  Thus,  the 
algorithm  for  handling  an  event  can  be  distributed  in  the  program  text.  This  feature  can  be 
useful,  as  discussed  next. 

A  real  time  program  for  controlling  a  physical  system,  such  as  a  car,  can  be 
constructed  as  a  collection  of  modules  that  reflects  the  structure  of  the  physical  system; 
each  program  module  will  correspond  to  some  physical  module.  Thus,  a  program  for 
controlling  a  car  may  contain  program  modules  that  correspond  to  the  ignition,  the  oil,  the 
brake  subsystems,  etc.  Each  such  program  module  encapsulates  all  the  necessary 
operations  related  to  the  corresponding  physical  module.  An  external  event  of  the  physical 
system  that  influences  several  physical  modules,  will  have  several  associated  event 
handlers  distributed  in  the  corresponding  program  modules.  Similarly,  a  regular  program 
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event  can  activate  several  event  handlers  distributed  In  the  program.  For,  example,  an 
event  from  the  class  check  can  initiate  checks  in  the  program  modules  that  correspond  to 
the  ignition,  the  oil,  the  brake  subsystems,  etc.  On  replacement  of  one  of  the  physical 
modules,  only  the  corresponding  program  module  has  to  be  mod'f'ed. 

3.4  Parallelism  in  the  Language 

Parallelism  in  an  EBL  program  Is  manifested  at  several  levels.  At  the  top  level, 
several  instances  of  event  handlers  can  be  executed  concurrently;  each  car  cause  new 
events  which  activate  more  Instances  of  event  handlers.  A  previous  section  demonstrates 
that  the  rate  of  spawning  new  activities  in  this  manner  is  high,  e.g.,  in  comparison  with 
MODULA.  At  a  lower  level,  when  an  instance  of  a  parallel  handler  is  activated  the  events 
specified  in  its  script  can  be  caused  concurrently.  Parallelism  at  the  above  two  levels  is 
explicit  in  the  language  definition.  The  followinr  analysis  shows  that  a  great  deal  of 
parallelism  can  be  exploited  at  a  lower  level;  this  applies  not  only  to  a  parallel  handler  but 
also  to  a  sequential  handler. 

Once  an  Instance  of  an  event  handler  is  activated,  all  the  data  needed  for 
evaluating  the  parameters  of  the  events  it  causes  are  available.  In  fact,  the  value  of  each 
parameter  Is  a  function  of  the  formal  parameters  in  the  event  handler  heading  and  of  some 
identifiers  (event  class  identifiers,  and  tag  identifiers).  The  values  associated  with  the 
Identifiers  in  an  expression  defining  a  parameter  of  an  event  to  be  caused  are  fixed  and 
cannot  be  modified  during  the  whole  computation.  Furthermore,  evaluating  those  functions 
causes  no  side  effects.  Therefore,  when  an  instance  of  an  event  handler  Is  activated  all 
event  parameters  In  its  script  can  be  evaluated  in  any  order  or  concurrently  (for  both  types 
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of  event  handlers). 

Earlier  it  was  argued  that  the  difference  between  a  sequential  handler  and  a 
parallel  handler  Is  that  the  events  caused  by  an  instance  of  a  sequential  handler  are 
ordered  by  the  precedes  relation,  whereas  those  caused  by  a  parallel  handler  are  not.  The 
above  discussion  shows  that  the  difference  Is  basically  in  the  order  in  which  the  event 
objects  containing  the  computed  parameters  are  Inserted  into  the  conceptual  event  lists.  In 
the  former  case  these  insertions  are  ordere  d  whereas  in  the  latter  case  they  are  not. 
Another  consequence  of  the  previous  discussion  is  that  once  an  Instance  of  an  event 
handler  is  activated  its  script  can  be  executed  in  a  finite  time.  All  the  data  needed  for  the 
execution  are  available;  therefore,  there  is  no  a  priori  need  to  suspend  it  during  the 
execution. 

3.5  Synchronization  Capabilities 

This  section  contains  a  comparison  of  synchronization  capabilities  In  EBL  with 
other  mechanisms  such  as  semaphores  and  monitors.  As  is  shown  in  chapter  6,  general 
semaphore  variables  [Di-68a,  Di-68b]  can  be  implemented  as  ev*-nt  class  identifiers  of  a 
single_use  recurrent  type.  (For  achieving  mutual  exclusion,  single_use  nonrecurrent 
events  are  sufficient.)  In  fact,  multiple  P  operations  [DI-71,  Pa-71]  can  be  easily 
expressed  In  the  language,  as  Is  shown  in  that  chapter.  singie_use  recurrent  events  are 
more  powerful  than  the  general  semaphore,  since  they  may  have  parameters  that  can  be 
used  to  carry  some  Information  in  addition  to  their  behavior  as  synchronization  primitives. 
The  counter  associated  with  a  semaphore  variable  is  implicitly  represented  by  the  number  of 
occurred  events  which  have  not  been  used  so  far;  i.e.,  the  number  of  existing  events  from 
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the  event  class  representing  the  semaphore. 

When  a  V  operation  is  executed  on  a  semaphore  variable,  one  of  the  currently 
waiting  processes  is  arbitrarily  selected  and  resumed.  EBL's  analogue  to  a  process  is  an 
instance  of  an  event  handler;  the  notion  of  a  waiting  process  is  not  applicable  since  there  is 
no  construct  similar  to  a  wait  statement  (although  such  behavior  can  be  easily  modeled). 
When  the  analogue  to  a  V  operation  is  executed  in  EBL,  it  guarantees  the  resumption  of 
some  "process"  executing  the  analogue  to  a  P  operation.  The  selection  of  this  process  is 
even  less  specified  than  in  the  case  of  semaphores  since  a  process  which  is  currently  not 
waiting  (but  will  start  waiting  sometime  in  the  future)  may  be  selected.  EBL's  predicates 
however,  provide  the  ability  to  explicitly  control  the  extent  of  fairness  of  an  algorithm,  as 
will  be  shown  in  chapter  6. 

The  obvious  difference  between  EBL's  events  and  the  monitor  construct  [BH-74, 
Ho-74],  Is  that  the  latter  is  more  structured.  The  mutual  exclusion  which  is  implicit  in  the 
monitor  must  be  explicitly  expressed  In  EBL  because  EBL's  events  are  primitive  objects 
which  are  closer  to  the  semaphores  than  to  the  monitor. 

The  implicit  mutual  exclusion  is  not  primitive  enough;  for  example.  If  a  process 
which  entered  the  monitor  decides  to  wait  for  some  condition  (which  depends  on  the 
monitor's  state  variables)  to  become  true  it  has  to  leave  the  monitor  and  reenter  in  the 
future.  In  order  to  prevent  this  form  of  busy  waiting  the  monitor  also  allows  explicit 
synchronization  operations  on  condition  variables.  It  might  be  Interesting  to  compare  the 
monitor  condition  variables  with  single_use  recurrent  events.  Signaling  a  condition  has  no 
effect  If  no  process  is  waiting  for  it;  i.e.,  no  memory  is  associated  with  monitor  conditions. 
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However,  In  EBL,  a  «ingle_use  recurrent  event  is  remembered  until  it  Is  used.  As  described 
in  [Wi-77c]t  a  deadlock  may  occur  when  trying  to  synchronize  parallel  processes  using  the 
monitor  condition  variables  (instead  of  using  semaphores)  because  of  the  lack  of  memory. 
This  kind  of  deadlock  cannot  occur  if  single_use  recurrent  events  are  employed  since  such 
events  are  not  forgotten  before  they  are  used;  l.e.,  before  they  have  some  effect. 

The  monitor  construct  also  allows  the  association  of  a  priority  with  a  waiting 
process  by  the  use  of  scheduled  waits.  A  comparison  of  this  feature  with  EBL's  mechanisms 
is  given  in  chapter  6  through  the  disk  head  scheduler  example. 

The  mechanism  used  for  synchronization  in  the  Actor  model  is  the  primitive 
serializer  [He-79].  In  the  Actor  model  two  kinds  of  actors  can  be  created:  an  unaerlallzed 
actor  and  a  serialized  actor.  An  actor  of  the  first  kind  can  receive  and  process  several 
messages  concurrently.  An  actor  of  the  latter  kind  processes  messages  one  at  a  time,  l.e.,  it 
serializes  them.  The  serialized  actor  becomes  locked  when  It  starts  processing  a  message; 
it  becomes  unlocked  when  processing  of  the  message  has  completed.  The  serialized  actor 
is  In  fact  an  adaptation  of  the  monitor  to  the  Actor  model. 

An  advantage  of  the  serialized  actor  over  the  monitor  Is  that  in  the  first  case, 
during  the  processing  of  a  request  operations  can  be  carried  out  concurrently,  whereas  in 
the  latter  case,  when  a  process  enters  a  monitor's  procedure  its  execution  proceeds 
sequentially.  EBL  shares  the  same  advantage  of  the  serialized  actor  over  the  monitor  In 
that  concurrency  can  be  employed  during  the  processing  of  a  request. 
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Both  structured  constructs,  the  monitor  and  the  serialized  actor,  can  be 
implemented  using  the  unstructured  constructs  semaphores  and  cells  (variables).  Since  the 
above  unstructured  constructs  can  be  expressed  in  EBL,  then  so  are  the  monitor  and  the 
serialized  actor.  The  state  of  a  monitor  is  kept  in  local  variables.  The  state  of  a  serialized 
actor  is  kept  In  Its  behavior  (another  actor);  this  behavior  can  be  modified  by  the  analogue 
of  an  assignment  statement,  a  become  command.  The  event  handlers  implementing  a  monitor 
do  not  have  any  state  information  associated  with  them.  This  demonstrates  the  uniqueness 
of  our  events:  the  event  used  to  synchronize  accesses  to  the  monitor  can  carry  as 
parameters  the  state  of  the  monitor. 

3.6  CSP,  Events,  and  Actors 

This  section  compares  certain  characteristics  of  communicating  sequential 
processes  (denoted  here  by  CSP)  [Ho-78a]  with  EBL.  In  addition,  some  of  the 
characteristics  are  also  compared  with  the  Actor  model  since  such  comparisons  give  a 
deeper  insight.  Since  CSP  is  a  process  based  model  some  of  the  points  discussed  earlier  in 
this  chapter  can  be  applied.  We  shall  not  repeat  the  discussion  here.  CSP  is  a  static 
language  in  several  respects.  For  a  given  program  the  maximum  number  of  concurrent 
processes  is  bounded.  Similar  limitations  do  not  exist  in  EBL  or  in  the  Actor  model.  A  given 
subprogram  which  recursively  computes  factorial(n)  can  do  so  only  for  n  smaller  than  some 
given  limit.  In  CSP  the  set  of  processes  with  which  a  given  process  can  communicate  is 
fixed  and  can  be  found  directly  from  the  program  text;  i.e.,  there  are  no  process  type 
variables  (in  contrast  to  local  variables  of  a  process  which  exist  in  CSP)  and  no  process 
type  parameters.  EBL  and  the  Actor  model  are  more  dynamic  In  nature.  The  first  allows  using 
event  class  identifiers  as  parameters  of  events,  and  the  second  allows  specifying 
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continuations;  both  features  are  similar.  The  feature  of  event  class  Identifiers  as 
parameters  does  not  complicate  the  Implementation  of  EBL  and  increases  its  modularity  and 
expressive  power.  This  feature  makes  programs  harder  to  analyze,  but  this  is  a  secondary 
issue  In  our  opinion. 

CSP  does  not  have  the  features  of  process  type  variables  or  process  type 
parameters.  This  limitation  together  with  the  property  that  each  process  must  explicitly 
name  the  destined  process  in  each  message  it  sends  do  not  allow  one  to  implement 
procedures  and  use  them  in  a  modular  manner,  in  particular  one  cannot  write  a  procedure 
named  S,  then  add  to  the  program  a  process  having  a  new  name  X  which  activates  S; 
knowledge  of  X  must  be  Incorporated  in  S.  in  EBL  procedures  can  be  expressed  in  several 
ways.  One  makes  use  of  event  class  Identifiers  as  parameters,  thus  allowing  continuations 
(see  chapter  5);  this  form  does  not  exist  in  CSP.  The  other  makes  use  of  tag  identifiers. 
Upon  termination  of  a  procedure  it  can  cause  an  event  from  a  fixed  event  class.  A 
parameter  of  this  event  can  be  a  tag  supplied  to  the  procedure  at  call  time  by  the 
activating  event.  This  scheme  can  be  viewed  as  a  generalization  of  the  use  of  an  array  of 
(not  necessarily  identical)  processes  P(i)  calling  the  same  procedure  in  CSP;  our  tags  are 
dynamic  in  contrast  to  the  static  nature  of  indexes. 

A  unique  characteristic  of  CSP  which  has  no  analogue  In  EBL  or  in  the  Actor  model 
is  that  a  receiver  must  explicitly  name  the  possible  senders.  In  CSP  the  sending  of  a 
message  Is  synchronized  with  the  receiving  of  the  message.  This  unique  feature  makes 
synchronization  of  processes  an  easy  task;  however,  It  has  several  drawbacks  which  are 
not  shared  by  EBL  or  by  the  Actor  model.  The  sender  cannot  proceed  until  the  receiver  is 
ready  to  accept  the  message.  Messages  sent  from  one  process  to  another  are  not 
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buffered;  both  EBL  and  the  Actor  model  have  unlimited  buffering  capability.  If  two  processes 
X  and  Y  exchange  messages  and  process  X  sends  a  nonmatching  message  to  process  Y 
then  a  deadlock  occurs  in  CSP.  In  the  Actor  model  Y  can  complain  about  the  message.  In  EBL 
the  chances  of  a  nonmatching  message  are  greatly  reduced  since  the  language  Is  strongly 
typed.  A  nonmatching  message  of  the  correct  type  can  be  dealt  with  in  any  desired  way; 
this  can  be  achieved  by  means  of  an  event  handler  whose  instances  are  activated  when 
such  nonmatching  messages  arrive. 

Another  important  difference  between  EBL  and  CSP  concerns  fairness.  In  this 
respect  EBL  is  distinguished  from  other  languages  as  well,  as  noted  in  chapter  2.  Consider 
the  following  program  (adopted  from  [Ho-78a]): 

stop,  terminated:  event  ; 

continue:  event  (int)  ; 

on  program_start 

par_cause  continue  (0)  ;  stop  {  initiate  } 

end  ; 

on  continue  (n:  Int)  a  stop 

par_cause  terminated  {  terminate  } 

end  ; 

on  continue  (n:  int) 

par_cause  continue  (n+1 )  {iterate} 

end  ; 

Our  fairness  rules  imply  that  this  program  eventually  terminates.  Hoare,  on  the  other  hand, 
does  not  require  from  implementation  of  CSP  to  be  fair;  thus,  the  analogous  program  In  CSP 
may  loop  forever.  A  similar  program  can  be  written  in  Actl.  The  first  event  handler  in  the 
above  program  can  be  replaced  by  one  actor  (ignoring  the  fact  that  the  two  messages  sent 
by  the  event  handler  are  not  ordered).  The  last  two  event  handlers  can  be  replaced  by  a 
serialized  actor  accepting  messages  of  two  kinds:  continue  and  stop.  The  obtained  Actl 
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program  Is  not  equivalent  to  the  above  program  but  it  is  sufficient  for  the  following 
discussion.  The  Actor  model  (correctly)  does  not  make  any  assumption  on  the  order  in  which 
two  messages  (e.g.,  continue  and  stop)  sent  from  one  actor  to  the  same  target  reach  their 
destination.  However,  since  a  serialized  actor  processes  messages  in  the  order  in  which 
they  are  received,  the  corresponding  Actl  program  stops  iterating  after  the  stop  message  is 
received. 


Suppose  knowledge  that  the  event  from  class  stop  has  occ  urred  is  brought  to 
knowledge  of  the  second  event  handler  (or  to  its  implementation)  at  t  ie  same  time  a  stop 
message  arrives  to  the  serialized  actor  (assuming  implementations  of  the  EBL  program  and 
the  Actl  program  run  concurrently  on  different  systems).  The  Actl  program  terminates  in 
the  next  iteration  of  the  serialized  actor.  EBL,  however,  only  guarantees  that  the  program 
eventually  terminates.  CSP  does  not  guarantee  termination  at  all;  the  process  trying  to  send 
the  stop  message  may  wait  forever  if  the  destined  process  decides  not  to  accept  the 
message. 

3.7  Relation  to  Pattern  Directed  Invocation  Languages 

Pattern  directed  invocation  languages  are  used  for  problem  solving  in  artificial 
Intelligence.  Their  development  started  by  Hewitt  [He-69]  and  is  still  in  progress.  Out  of 
these  languages,  the  one  which  is  most  reminiscent  of  ours  is  ETHER  [Ko-70].  (Its 
existence  was  brought  to  our  attention  by  Hewitt  toward  the  completion  of  our  research,  in 
the  spring  of  1979.)  A  subset  of  ETHER  resembles  an  earlier  version  of  EBL  (which  has 
developed  since).  ETHER'S  sprites  and  assertions  are  analogous  to  EBL's  event  handlers 
and  events  respectively.  More  precisely,  an  ETHER  assertion  Is  analogous  to  a  multi_use 
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n ">n_recurrent  event.  The  lack  of  the  analogues  to  ERL's  other  event  types  in  ETHER 
suggests  that  certain  computations  which  can  be  expiessed  in  EBL  cannot  be  expressed  in 
ETHER.  Our  slngle_use  events  support  modeling  of  mutable  objects  and  synchronization 
primitives;  these  cannot  be  modeled  in  ETHER. 

In  ETHER  a  sprite  can  contain  other  sprites;  the  inner  sprites  are  exposed  after 
the  containing  sprite  is  activated.  An  earlier  version  of  EBL  also  allowed  nested  event 
handlers  but  this  feature  was  eliminated  from  the  language  in  favor  of  multiple  event 
descriptors  in  an  event  handler  heading.  The  expressive  power  in  both  cases  seems  similar 
when  only  multi_use  events  are  employed.  However,  when  single_use  events  are  allowed 
the  feature  of  multiple  event  descriptors  increases  the  expressive  power;  e.g.,  a  multiple  P 
operation  can  be  easily  expressed  in  this  case.  Another  prime  factor  in  our  decision  to 
eliminate  nested  event  handlers  is  ease  of  implementation.  In  the  current  version  of  EBL  the 
number  of  event  handlers  exposed  at  any  point  in  time  is  fixed  and  they  all  operate  in  the 
same  environment  (except  the  static  effect  of  modules).  When  nested  event  handlers  are 
allowed,  the  number  of  exposed  event  handlers  vary  with  time  and  they  do  not  operate  in 
one  environment,  but  rather,  nested  environments  are  needed. 

The  mechanism  by  which  a  sprite  decides  whether  an  assertion  matches  it  is 
comparison  of  the  assertion  to  a  specific  pattern.  This  is  less  powerful  than  the  mechanism 
used  in  EBL  which  allows  a  generai  boolean  expression  (and  predicates)  for  this  purpose. 

ETHER  is  based  on  broadcast  and  pattern  matching  mechanisms  but  it  relies  on  other  control 
mechanisms  as  well.  For  example,  conditional  constructs  are  allowed  within  the  body  of  a 
sprite.  As  another  example,  ETHER  allows  a  sprite  to  explicitly  abort  some  activity  in 
progress  by  using  a  special  construct  {stifle).  No  special  construct  is  needed  in  order  to  \ 
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achieve  this  effect  In  EBL.  A  subcomputation  can  be  aborted,  and  even  be  resumed,  using 
the  basic  event  mechanism  (by  including  the  predicates  exist  or  none  in  event  handler 
headings). 

3.8  Relation  to  Production  Systems 

The  structure  of  an  EBL  program  is  reminiscent  of  a  collection  of  productions  in  a 
production  system  [Wi-77a].  An  event  handler  is  the  analogue  of  a  production.  The  event 
handler  heading  corresponds  to  the  situation  recognition  part,  and  the  event  handler  script 
to  the  action  part.  A  production  whose  situation  recognition  part  is  a  conjunction  of 
conditions  can  be  easily  expressed  in  EBL  since  an  event  descriptor  list  is  a  conjunction  of 
event  descriptors.  A  production  whose  situation  recognition  part  is  a  disjunction  of  n 
conditions  can  be  expressed,  for  example,  as  n  event  handlers  with  Identical  scripts.  The 
common  script  causes  a  multi_use  non__recurrent  event  which  activates  the  action  part  of 
the  production  (another  event  handler). 

In  a  deduction  oriented  production  system  [Wi-77a]  one  normally  begins  with  a 
collection  of  facts  and  tries  to  reach  a  goal  (in  forward  chaining  mode).  A  fact  may  be  used 
several  times  in  the  process  of  moving  toward  the  goal;  in  addition,  a  fact  may  be 
established  more  than  once  in  that  process.  Therefore,  our  multi_use  non_recurrent 
events  are  appropriate  for  such  systems.  In  order  to  solve  several  unrelated  instances  of  a 
problem  concurrently  one  can  simply  use  tags  to  obtain  the  desired  behavior.  In  other  types 
of  production  systems  slngle_use  events  can  be  employed.  For  example,  In  a  system  for 
manipulating  objects,  once  an  action  in  a  sequence  of  actions  to  be  performed  is  taken 
there  is  no  need  to  remember  it. 
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The  fundamenta1  difference  between  production  systems  and  our  model  is  that 
the  first  is  a  sequential  model  whereas  the  second  is  a  parallel  model.  Productions  are 
invoked  one  at  a  time.  If  several  productions  can  be  invoked  at  some  point  then  the  next 
production  is  selected  according  to  priority  or  some  heuristic  algorithm.  Such  a  behavior  can 
be  modeled  in  EBL  but  better  alternatives  are  available  in  EBL.  In  a  deduction  oriented 
system,  for  example,  all  possible  paths  can  be  pursued  concurrently.  (ETHER  [Ko-79]  is 
based  on  this  idea.) 

3.9  Relation  to  Petri  Nets 

The  modeling  power  of  Petri  nets  is  less  than  that  of  Turing  machines  [Pe-77]. 
Therefore,  one  cannot  expect  that  a  program  in  EBL,  which  is  clearly  a  universal  language, 
could  be  modeled  accurately  by  a  Petri  net.  However,  If  one  agrees  not  to  model  data 
dependency  in  a  program,  in  particular  to  ignore  all  where  clauses  (i.e.,  to  assume  that  they 
are  true  for  each  event  collection),  then  a  Petri  net  can  be  created  for  many  programs  (or 
subprograms)  in  EBL.  A  Petri  net  can  be  created  for  every  EBL  program  satisfying  the 
following  conditions: 

PI.  Each  event  handler  H  contains  exactly  one  event  descriptor  in  its  event 
descriptor  list,  or  at  least  one  of  its  event  descriptors  is  associated  with  an 
event  class  Identifier  of  a  single_use  type. 

P2.  There  are  no  event  class  identifiers  of  non_recurrent  types. 

P3.  There  are  no  formal  parameters  of  type  event. 

In  order  to  show  how  the  Petri  net  Is  created  we  begin  with  a  program  in  which  in  addition  to 
the  above  conditions  all  event  class  identifiers  are  of  single_use  types. 
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The  basic  method  is  to  associate  one  place  with  every  event  class  identifier  of  a 
single_use  recurrent  type,  and  one  transition  with  every  event  handler.  The  script  of  a 
parallel  handler  Is  modeled  by  arcs  going  from  the  transition  associated  with  the  event 
handler  to  the  places  associated  with  the  classes  of  the  caused  events.  In  case  of  a 
sequential  handler,  the  script  is  modeled  by  a  chain  consisting  of  arcs  places  and  transitions 
starting  at  the  transition  associated  with  the  event  handler.  The  chain  reflects  the  order  in 
which  the  events  are  caused.  An  additional  arc  goes  from  each  transition  in  the  chain  to  the 
place  associated  with  the  class  of  the  caused  event.  Figure  3.1  depicts  the  Petri  net 
corresponding  to  the  following  subprogram,  in  which  all  event  class  Identifiers  are  of  a 
single_use  recurrent  type. 

on  PI  (i:  Int)  a  P2  (J:  int)  where  i>j 
par_cause 

PI  (i-1)  ;  P3  (j+1) 

end  ; 

on  PI  (i:  int)  a  P3  (j:  int)  where  l=j 
«eq_cau*e 

PI  (1*1)  ;  P2  (j+2) 

end  ; 


Figure  3.1  Petri  net  representetlon  of  e  subprogram 


The  above  scheme  may  require  multiple  arcs  connecting  a  place  and  a  transition  (in  the 
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same  direction).  Such  generalized  Petri  nets  are  equivalent  to  ordinary  Petri  nets  [Pe-77]. 

The  modeling  of  multi_use  events  requires  some  sophistication  but  is  still  not 
complicated  if  conditions  P1-P3  are  satisfied.  Suppose  P(  is  a  place  associated  with  an 
event  class  identifier  of  a  multi_use  recurrent  type  appearing  in  the  headings  of  n  event 

handlers  H^...  ,Hn;  n  additional  places  P^ . Pjn  are  created.  The  Input  arc  to  the 

transition  associated  with  Hj  comes  from  Pjj  instead  of  from  Pj;  an  output  arc  goes  from  that 
transition  to  P^.  There  is  only  one  outgoing  arc  from  it  goes  to  a  transition  whose  n 
outgoing  arcs  go  to  Pf1 , ...  ,  Pjn.  This  solution  simply  copies  the  tokens  of  P|  to  n  places  Pjj. 
each  associated  with  one  event  handler,  and  recreates  them  in  each  P^  whenever  they  are 
swallowed.  Figure  3.2  depicts  the  Petri  net  obtained  If  in  the  previous  example  P'1  is 
changed  to  be  of  a  multi_use  recurrent  type. 


The  scheme  presented  above  does  not  reflect  the  existence  of  event  parameters.  Since  a 
non_recurrent  event  is  caused  only  If  an  identical  event  (an  event  from  the  same  event 
class  having  the  same  parameters)  does  not  currently  exist,  this  scheme  is  not  appropriate. 
The  scheme  can  be  extended  in  order  to  model  non_recurrent  events  without  parameters 
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bi;t  we  shall  not  do  so.  Ordinary  Petri  nets  are  sufficient  in  this  case;  in  particular,  there  is 
no  need  for  zero  testing  [Pe-77]. 

Another  difficulty  is  the  use  of  formal  parameters  of  type  event.  The  problem  is 
that  the  class  of  an  event  whose  class  designator  Is  a  formal  parameter  cannot  be 
determined  from  the  script  of  the  event  handler  and  Is  not  fixed.  As  an  approximation,  one 
can  find  the  set  S  of  all  possible  event  class  identifiers  to  which  such  a  formal  parameter 
can  be  bound.  S  can  be  found  by  a  simple  algorithm  based  on  transitive  closure.  The  part  of 
the  Petri  net  corresponding  to  the  event  having  the  formal  parameter  class  designator  will 
simply  add  a  token  to  one  of  the  places  corresponding  to  the  elements  of  S. 

The  other  direction  is  more  successful:  each  Petri  net  can  be  easily  expressed 

as  an  EBL  program.  A  single_use  recurrent  event  class  identifier  (without  parameters)  is 

•  •  *  * 

associated  with  each  place  in  the  net.  Each  transition  is  described  by  a  parallel  handler 

whose  script  causes  events  from  the  appropriate  classes.  The  following  program 

represents  the  Petri  net  of  Figure  3.1 : 

PI,  92,  P3,  P4:  event  ; 

on  PI  a  92 

par_cause  PI  •,  P3 
end  ; 

on  PI  a  P3 

par_cause  PI  ;  P4 
end  ; 

on  P4 

par_cause  92 
end  ; 

The  initial  marking  of  the  Petri  net  can  be  easily  programmed.  One  way  is  to  cause  events 
corresponding  to  the  initial  tokens  in  one  or  more  event  handlers  activated  by  the  event 
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from  the  class  program_start.  In  this  case,  slngle_use  recurrent  events  without 
parameters  and  parallel  handlers  without  where  clauses  are  sufficient  to  describe  any  Petri 
net.  Another  approach  Is  first  to  cause  the  above  events  and  then  to  enable  the  rest  of  the 
event  handlers  by  causing  an  event  from  the  class  start. 

There  are  two  ways  In  which  an  event  handler  H  can  check  the  start  condition.  In 
the  first  way,  the  where  clause:  where  exist  (start)  is  added  to  the  heading  of  H;  here, 
start  can  be  o‘i  a  single_use  or  a  mutti_usa.  In  the  second  way,  an  event  descriptor  of  the 
form:  a  start  is  added  to  the  event  descriptor  list  of  H.  Here,  start  can  be  of  a  multl_use  or 
a  single_use  type;  in  the  latter  case,  an  instance  of  H  should  cause  another  event  from  the 
class  start  in  order  to  enable  other  event  hi  ndlers  (since  it  uses  one  when  it  is  activated). 

3.10  Relation  to  Databases 

An  analogy  can  be  drawn  between  the  language  and  data  manipulation  languages 
for  relational  databases.  An  event  class  is  analogous  to  a  relation,  and  each  event  to  a 
tuple  In  a  relation.  The  structure  of  an  event  handler  (in  particular  its  heading)  brings  to 
mind  a  query  written  in  a  data  manipulation  language  such  as  SEQUEL  [Ch-74a].  They  both 
define  a  nonprocedural  operation  to  be  performed  by  the  system.  The  difference  is  that 
once  a  query  is  initiated,  It  runs  to  completion  and  then  vanishes  while  the  database 
continues  to  change.  An  event  handler,  on  the  other  hand,  is  immortal;  it  stays  alive  as  long 
as  there  is  a  possibility  of  change  In  any  of  the  event  classes  (and  when  no  such  change 
can  happen,  the  whole  program  terminates).  It  Is  analogous  to  a  query  whose  execution 
never  terminates.  In  order  to  model  a  database  in  EBL  some  scheme  for  achieving  mutable 
objects  is  needed.  Such  schemes  are  presented  in  chapter  5,  and  in  the  readers  writers 
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problem  in  chapter  6. 

3.1 1  Summary 

This  chapter  has  exposed  some  of  the  important  properties  of  EBL  by 
comparisons  to  other  mechanisms.  The  language  constructs  are  primitive;  nevertheless,  the 
capability  of  hierarchical  program  design  is  provided  by  modules.  Other  forms  of  modularity 
which  are  provided  by  the  language  have  been  discussed.  A  great  deal  of  parallelism  can 
be  exploited  in  an  EBL  program.  New  activities  can  be  easily  spawned,  synchronized,  and 
joined.  P  operations  (and  multiple  P  operations)  and  V  operations  on  semaphores,  monitors, 
and  serialized  actors  can  be  expressed  in  EBL. 

Our  model  shares  some  of  its  characteristics  with  other  models  of  computation; 
however,  important  differences  exist  in  each  case.  This  chapter  developed  the  relation 
between  the  language  and  other  models  such  as:  message  passing  models,  communication 
sequential  processes,  pattern  directed  invocation  languages,  production  systems,  Petri 
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4.  Definition  of  the  Language 

This  chapter  completes  the  definition  of  the  language,  whose  main  concepts  have 
already  been  defined  in  the  previous  chapters.  It  contains  a  definition  of  the  syntax  and 
semantics  of  EBL.  A  formal  definition  of  the  syntax  is  contained  in  appendix  A;  it  should 
serve  as  a  convenient  reference,  and  we  have  not  included  the  formal  definition  here  to 
avoid  redundancy.  Appendix  A  is  ordered  according  to  the  sections  of  this  chapter,  and  we 
suggest  that  before  (or  while)  reading  each  section  of  this  chapter,  the  reader  will  examine 
the  syntactic  structure  from  the  corresponding  section  in  appendix  A.  The  following 
conventions  are  used: 

1 .  The  syntax  is  described  in  an  extended  Backus-Naur  form. 

2.  A  construct  enclosed  by  the  braces  must  be  repeated  at  least  m  times  and 

at  most  n  times.  The  default  values  are  m=0  and  n=». 

3.  Keywords  of  the  language  are  printed  as  bold  face  characters  in  this  thesis. 

in  contrast  to  the  meta-language  braces  EBL  contains  the  braces  {...} 

which  are  used  to  indicate  the  beginning  and  the  end  of  a  comment.  Comments  can  be 
inserted  between  any  two  symbols  in  the  program  and  have  no  effect  on  the  meaning  of  the 
program;  comments  may  be  nested.  The  chapter  starts  with  the  basic  constructs;  proceeds 
with  the  definitions  of  types,  declarations,  expressions;  and  ends  with  event  handlers, 


modules  and  programs. 
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4.1  Identifiers  and  Numbers 

Identifiers  serve  to  denote  objects  in  the  language.  The  objects  are  formal 
parameters,  event  classes,  tags,  and  types.  The  association  of  Identifiers  and  objects  must 
be  unique  within  the  scope  of  declaration  of  the  identifiers.  Scope  rules  are  given  in  the 
section  on  event  handlers  and  the  section  on  modules.  In  various  places  in  this  thesis 
subscripts  are  used  within  identifiers  (e.g.,  E()  although  this  is  not  allowed  by  the  syntax. 
The  character  set  is  an  ordered  set  of  all  legal  characters  in  EBL.  It  contains  all  digits, 
letters,  and  special  characters  in  the  order  in  which  they  are  listed  in  appendix  A. 

Examples  of  identifiers : 

n  {  formal  parameter  identifier  } 

sum_f  {  event  class  identifier  } 

t  {  tag  identifier  } 

4.2  Constants 

Constants  appear  In  expressions.  Each  constant  has  a  certain  type  associated 
with  it,  as  explained  in  the  following  section. 

Examples  of  constants s 


-60 

{  Integer  constant } 

true 

{  boolean  constant } 

'a 

{  character  constant } 

I 
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4.3  Types  and  Type  Identifiers 

Every  constant,  identifier,  or  expression  has  a  type  associated  with  it.  The  type 

* 

determines  the  set  of  values  that  an  object  of  that  type  can  assume,  as  well  as  its 
semantics.  The  basic  types:  int,  bool  and  char  have  the  conventional  meanings.  The  values 
associated  with  objects  of  type  tag  are  obtained  from  the  global  tag  set,  as  explained  in 
chapter  2.  An  event  type  represents  a  group  of  events.  Each  event  has  a  fixed  number  of 
parameters  associated  with  it,  each  of  a  distinct  type  determined  by  the  corresponding 
type  in  the  type  list  of  the  event  type.  An  event  type  contains  two  optional  orefixes.  The 
default  prefixes  are:  single_use,  and  recurrent.  A  type  can  be  denoted  by  a  type 
identifier,  as  explained  in  the  next  subsection. 

Examples  of  types : 

Int 

event  (tag,  int)  {  single_use  recurrent  by  default  } 

multi_use  event  (bool,  tag)  {  recurrent  by  default  } 
cont  {  type  identifier  } 

4.3.1  Type  Identifier  Definition 

A  type  Identifier  is  equated  with  a  list  of  one  or  more  typ^s.  It  can  be  used  as  a 
shorthand  notation,  or  as  a  means  for  type  abstraction.  It  should  be  emphasized  that  if  a 
type  identifier  is  used  at  any  level  of  nesting  within  the  module  in  which  it  has  been  defined, 
then  its  structural  details  are  known  at  that  point;  otherwise  (outside  the  module),  only  its 
name  may  be  known.  The  ability  to  denote  a  list  of  known  types  by  a  single  type  Identifier 
allows  one  to  bind  a  single  formal  parameter  of  that  type  to  a  list  of  actual  event 
parameters,  when  no  computation  needs  to  be  performed  on  them.  An  example  of  this 
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feature  la  given  in  the  section  on  event  handlers. 

Examples  of  type  Identifier  definitions: 

cont,  tl  ==  single_use  recurrent  event  (Int,  tag)  ; 

{  both  cont  and  tl  represent  the  same  type  } 

X2  ==  int,  tag  ;  {  t2  represents  a  list  of  types  > 

t3  ==  single_use  recurrent  event  (t2)  ; 

{  t3  Is  identical  to  tl  only  if  the  structural  details  of  t2  are  known  } 

4.4  Declarations 

The  term  declarations  actually  refers  to  both  declarations  and  definitions.  Type 
identifier  definition  has  already  been  described.  The  declarations  of  event  handlers  and 
modules,  which  are  more  complicated,  are  described  later  in  the  corresponding  sections; 
event  class  identifier  declarations  and  tag  identifier  declarations  are  described  next. 

4.4.1  Event  Class  Identifier  Declaration 

An  event  class  declaration  associates  event  class  Identifiers  with  an  event  type, 
or  with  a  type  identifier  whose  structure  is  known  as  equivalent  to  an  event  type.  Each 
event  class  identifier  denotes  a  class  of  distinct  events  of  the  event  type.  An  event  from 
the  event  class  is  determined  by  the  event  class  identifier  and  the  values  of  Its 
parameters.  Before  execution  of  the  program  is  started,  no  event  from  the  declared  event 
class  has  occurred.  Events  are  considered  to  have  occurred  after  they  are  caused  either 
explicitly  by  execution  of  the  script  of  an  instance  of  some  event  handler,  or  after  the 
system  has  caused  them.  The  system  can  cause  either  system  events  or  events  from  a 
class  whose  event  class  identifier  appears  as  a  parameter  of  a  system  event.  This 
happens,  for  example,  after  some  system  activity  has  beer  completed,  or  when  some 
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external  signal  has  been  detected,  depending  on  the  semantics  of  the  particular  system 
event. 

Examples  of  event  class  declarations : 

sum_f:  single_use  recurrent  event  (int,  int)  ; 

suml,  sum2:  cont  ;  {  cont  is  known  to  be  an  event  type  } 

4.4.2  Tag  Identifier  Declaration 

The  semantics  and  use  of  tags  have  been  described  n  chapter  2.  Note  that  the 
value  associated  with  a  tag  identifier  cannot  be  modified,  it  can  be  copied  as  a  parameter 
of  several  events;  it  can  be  compared  with  those  of  other  tag  identifiers  or  formal 
parameters  of  type  tag,  but  there  are  no  other  operations  that  can  be  done  on  objects  of 
that  type. 

Examples  of  tag  Identifier  declarations : 

tl ,  t2:  tag  ;  {  assume  values:  «t,  and  fi  respectively  } 

4.5  Expressions 

Expressions  in  EBL  are  rather  conventional.  They  consist  of  operands  (constants 
or  Identifiers)  and  operators.  An  operator  operates  on  arguments  (operands  or 
subexpressions)  whose  types  must  be  consistent  with  the  operator.  Operator  precedence 
is  determined  from  the  syntax  of  the  expression.  A  sequence  of  operators  with  equal 
precedence  is  executed  from  left  to  right.  Some  of  the  operators  in  the  language  are  called 
built-in  functions ;  these  are  in  general  more  complex  operators,  but  they  have  nothing  to  do 
with  conventional  functions.  Each  expression  has  a  type  associated  with  it;  this  type  is 
either  a  basic  type  (int,  bool,  or  char),  or  a  non-baslc  type;  the  expressions  are  named 
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accordingly. 

4.5.1  Integer  Expression 

The  operators  in  an  integer  expression  are  +  (plus),  -  (minus),  *  (multiply),  / 
(divide),  div  and  mod.  They  operate  on  arguments  of  type  int  and  yield  values  of  type  Int. 
The  operator  /  performs  division  with  truncated  fraction.  In  case  of  the  operators  div  and 
mod  the  divisor  must  be  positive.  The  operator  div  yields  the  largest  integer  not  greater 
than  the  value  of  the  mathematical  division.  The  other  operators  have  their  conventional 
meanings.  The  built-in  functions  are: 

1.  abs  which  operates  on  an  argument  of  type  int  and  yields  a  value  of  type  int, 
which  equals  the  absolute  value  of  the  given  argument. 

2.  ord  which  operates  on  an  argument  of  type  char  and  returns  the  ordinal  number 
of  the  argument  value  in  the  character  set. 

Examples  of  integer  expressions: 
n-1 

-(rl  +  r2)  /  (i  div  J)  +  abs  (k) 

4.5.2  Boolean  Expression 

The  constants  of  type  bool  are  true  and  false.  The  operators  in  a  boolean 
expression  are  the  boolean  operators :  not  ,  and  ,  or,  and  xor;  and  the  relational  operators: 
<,  <=,  *,  <>,  >s,  >.  The  former  have  their  conventional  meanings  and  operate  on  arguments 


of  type  bool  yielding  a  boolean  value.  Relational  operators  yield  a  boolean  value  but  can 
operate  on  arguments  which  are  not  necessarily  of  type  bool.  The  operators  =  (equal)  and 
<>  (not  equal)  can  operate  on  any  two  arguments  of  the  same  type.  The  values  of  the 


Boolean  Expression 


-  79  - 


Section  4.5.2 


arguments  are  compared  and  the  resulting  value  is  determined  accordingly.  The  meaning  of 
equality  is  determined  as  follows: 

1 .  The  result  of  comparing  two  expressions  of  a  basic  type  is  self  explanatory. 

2.  The  result  of  comparing  two  identifiers  of  type  tag  by  the  operator  =  is  true,  if 
they  have  the  same  abstract  value,  from  the  global  tag  set,  associated  with  each 
of  them.  In  the  case  of  two  distinct  identifiers,  this  may  happen  only  if  at  least 
one  of  the  arguments  is  a  formal  parameter  of  type  tag. 

3.  Two  identifiers  of  type  event  are  equal  if  they  represent  the  same  event  class 
(a  formal  parameter  of  type  event  represents  the  class  of  events  to  whose 
event  class  identifier  it  is  bound). 

4.  The  result  of  comparing  two  formal  parameters  of  a  type  denoted  by  a  type 
identifier  that  represents  a  list  of  types  is  determined  as  follows:  The  two 
arguments  are  considered  equal  if  each  of  their  corresponding  subcomponents 
are  equal  according  to  these  definitions. 

5.  Two  identifiers  of  types  whose  structural  details  are  not  known  at  that  point  in 
the  program  must  be  formal  parameters,  they  can  be  compared  with  each  other 
only  if  they  are  of  the  same  type  (denoted  by  a  type  Identifier).  For  the 
comparison  the  structural  details  of  the  common  type  are  made  known  and  the 
result  of  the  comparison  is  determined  according  to  the  above  definitions.  Note 
that  comparison  of  objects  whose  common  type  is  not  fully  known  at  some  point 
In  a  program  is  normally  done  by  using  a  special  equality  operator  which  is 
defined  at  the  same  program  module  in  which  the  commor  type  is  defined  (see  for 
example  MODULA  [Wi-77b]).  The  more  liberal  use  of  the  standard  comparison 
operators  (=  and  <>)  in  EBL  is  motivated  by  the  relatively  high  frequency  of 
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comparisons  in  programs. 

The  operators  <,  <=,  >=,  and  >  operate  on  two  values  of  type  int. 

Examples  of  boolean  expressions : 
c  <=  n  and  not  b 

tl  =  t2  {  comparison  of  tags  } 

bl  <>  b2  {  when  both  are  formal  parameters 

of  a  type  defined  as:  t2  ==  int,  tag  } 


4.5.3  Character  Expresssion 


A  character  expression  can  be  a  constant  (a  character  preceded  by  a  quote),  a 
formal  parameter  of  type  char,  or  an  activation  of  the  built-in  function  chr.  The  built-in 
function  operates  on  an  argument  of  type  int  and  returns  the  character  whose  ordinal 
number  In  the  character  set  is  equal  to  the  value  of  the  argument  (if  such  a  character 
exists). 

Examples  of  character  expressions : 

'a 

formal_char  {  formal  parameter  of  type  char  } 


4.5.4  Non-Basic  Expression 

A  non-basic  expression  is  an  expression  whose  type  Is  not  a  basic  type.  The 
common  characteristic  of  all  non-basic  expressions  is  that  they  contain  no  operators.  They 
can  be  subdivided  as  follows: 

1.  The  expression  is  of  type  event.  In  this  case,  it  can  be  either  an  event  class 
identifier,  or  a  formal  parameter  of  the  correct  event  type.  In  both  cases,  the 
value  of  the  expression  is  the  name  of  the  denoted  event  class  identifier. 
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2.  The  expression  is  of  type  tag.  In  this  case,  the  expression  is  either  a  tag 
identifier,  or  a  formal  parameter  of  type  tag.  In  both  cases,  the  value  of  the 
expression  is  the  unique  value,  from  the  tag  set,  associated  with  the  identifier  in 
the  expression. 

3.  The  expression  is  a  formal  parameter  of  a  type  denoted  by  a  type  identifier  that 
represents  either  a  list  of  types,  or  a  type  whose  structural  details  are  not 
known  at  that  point  in  the  program.  In  both  cases,  the  value  of  the  expression  is 
the  value  to  which  the  formal  parameter  is  bound. 

Examples  of  non-basic  expressions: 

c  {  formal  parameter  of  some  eve  >  type  } 

t  {  tag  identifier  } 

rec  {  formal  parameter  of  a  type  defined  as: 

record  ==  int,  int,  bool  } 

4.6  Event  Handlers 


The  event  handler  concept  has  been  explained  at  some  length  in  chapter  2. 
Here,  some  additional  details  are  given.  When  an  instance  of  an  event  handier  is  activated, 
first  its  local  identifiers  are  brought  into  existence:  its  formal  parameters  are  bound  to  the 
corresponding  actual  parameters  of  the  activating  events,  and  its  tag  identifiers  assume 
proper  unique  values  from  the  tag  set.  Then,  the  script  of  the  event  handler  is  executed 
(i.e.,  the  specified  events  are  caused).  The  instance  of  the  event  handler  is  active  from  the 
moment  it  has  been  activated  until  the  execution  of  its  script  has  been  completed. 
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The  scope  of  a  formal  parameter  in  the  event  handler  heading  includes  the  whole 
event  handler;  whereas,  the  scope  of  a  tag  identifier  includes  thf  whole  script.  Free 
identifiers  in  some  part  of  the  event  handler  must  be  known  at  the  the  containing  module 
body.  Note  that  formal  parameters  and  tag  identifiers  declared  in  an  event  handler  are  local 
identifiers  of  that  handler;  they  are  not  known  outside  the  handler  and  there  is  no  way  of 
exporting  their  names.  The  following  example  shows  how  type  identifiers  can  be  used  to 
abstract  the  values  of  some  parameters: 

record  ==  int,  int,  bool  ; 

E,  E2:  event  (record,  int)  ; 

on  E  (r:  record,  I:  int)  where  i<100 
par  cause 

E  (r,  i+1)  ;  E2  (r,  1-1 ) 

end  ; 

on  E  (11,  12:  int,  b:  bool,  i:  int)  where  i>=100 
seq_cause 

E  (-11, 11  -i2,  not  (b),  0)  ; 

end  ; 

In  the  first  event  handler,  no  computation  needs  to  be  done  on  the  values  of  the  first  three 
parameters  of  the  event  from  class  E.  They  are  bound  to  one  formal  parameter  that  can  only 
be  copied  in  the  script.  In  the  second  handler,  the  values  are  needed  for  some 
computations,  so  they  have  been  bound  to  separate  formal  parameters.  Note  that  if  record 
were  defined  in  a  module  not  containing  the  above  handlers,  and  were  appropriately 
imported  to  the  module  containing  the  above  handlers,  then  only  the  top  handler  would  be 
legal.  The  structural  details  of  the  type  identifier,  record,  are  not  known  here  in  this  case. 

An  event  class  is  denoted  in  an  event  handler  either  by  an  event  class  identifier, 
or  by  a  formal  parameter  of  an  event  type  (that  is  bound  to  an  event  class  identifier).  In 
both  cases  we  say  that  the  class  is  denoted  by  a  class  designator. 
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4.6.1  Where  Clause  Predicates 

The  language  contains  special  predicates  that  can  be  used  in  the  where  clause 
of  an  event  handler  to  specify  constraints  on  the  order  of  choosing  event  collections  to 
activate  instances  of  that  event  handler.  These  predicates  are  appended  to  the  (optional) 
boolean  expression  in  the  where  clause.  The  semantics  of  the  where  clause  is  that  in  order 
to  activate  an  instance  of  an  event  handler  for  a  collection  of  events,  the  value  of  the 
boolean  expression  must  be  true  (if  it  exists),  and  in  addition,  all  the  predicates  must  be 
satisfied  for  those  events.  Several  predicates  can  appear  in  the  same  condition;  in  such 
case  they  are  processed  from  left  to  right.  The  action  of  evaluating  the  where  clause  (in 
particular,  the  predicates)  and  selecting  an  event  collection  out  of  the  various  candidates  is 
atomic;  it  can  be  viewed  as  an  action  which  takes  zero  time.  The  meanings  of  the  different 
predicates  are  defined  below. 

1.  exist:  T  he  argument  specifies  the  name  of  an  event  class.  The  predicate  is 
satisfied  If  at  least  one  event  of  that  event  class  currently  exists;  e.g., 

on  Ej  (i,  J:  int)  where  (i>0)  a  exist  (Eg) 

2.  none:  The  dual  of  exist.  The  predicate  Is  satisfied  if  no  event  of  the  specified 
event  class  currently  exists. 

3.  min:  The  value  of  the  (integer)  argument  Is  the  minimum  over  all  possible 
codec  ons  of  existing  events  that  match  the  part  of  the  event  handler  heading 
to  the  left  of  the  min  predicate;  e.g., 

on  E1  (),  j:  int)  where  min  (i-j) 

4.  max:  The  dual  of  min;  e.g., 


Section  4.6.1 


-  84  - 


Where  Clause  Predicates 


on  E1  (i,  j:  int)  where  (i<0)  \  max  (i) 

{  choose  an  event  from  E  j  with  maximum  negative  parameter  } 

5.  first:  The  argument  specifies  the  name  of  an  event  class  (by  means  of  an  event 
class  identifier  without  a  formal  parameter  list),  or  an  event  that  is  a  candidate 
to  activate  an  instance  of  the  event  handler  (by  including  the  formal  parameters 
of  an  event  descriptor  from  the  heading).  In  both  cases,  the  specified  event 
class  must  be  one  of  the  event  classes  specified  in  the  event  descriptor  list  of 
this  event  handler.  The  selected  event  occurred  first  among  all  existing  events 
from  the  denoted  class  that  match  the  part  of  the  event  handler  heading  to  the 
left  of  the  first  predicate;  e.g., 

on  (i,  j:  Int)  where  (i>j)  a  first  (E-j) 

{  choose  the  first  event  from  E-j  for  which  i>j  } 

on  E1  (I,  j:  int)  a  E-j  (p,  q:  Int)  where  (i>j)  a  first  (E1  (I,  j:  Int)) 

{  choose  the  first  event  from  E^  for  which  i>j, 
and  another  one  arbitrarily  } 

6.  last:  The  dual  of  first;  e.g., 

on  E-j  (I,  j:  Int)  where  last  (E-j )  {  last  in  first  out  order  } 

Note  that  one  of  the  properties  of  the  above  predicates  Is  that  if  they  are  evaluated  for  the 
same  collection  of  events  at  two  different  points  In  time  their  values  may  change  (due  to 
the  possible  creation  and  disappearance  of  other  events). 

4.7  Modules 

Most  features  of  the  module  have  already  been  described.  If  a  module  does  not 
contain  an  import  list,  none  of  the  Identifiers  declared  or  defined  outside  it  can  be 
referenced  within  its  body.  Clearly,  such  a  module  Is  not  interesting  since  none  of  its 
handlers  can  ever  be  activated.  The  other  extreme  case  is  that  of  a  module  that  Imports  all 
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identifiers  known  out  of  its  body.  This  can  be  achieved  by  using  the  keyword  all,  or  by 
explicitly  listing  ail  identifiers.  This  case  is  not  useless;  it  allows  declarations  of  local 
identifiers  within  this  module,  and  exportation  of  some  of  them  If  needed.  All  Identifiers 
known  within  a  module  body  can  be  exported  by  using  the  keyword  all  in  the  export  list. 


The  scope  of  an  identifier  declared  (or  defined)  in  a  module  body  includes  every 
event  handler  declared  in  that  body  (unless  that  handler  uses  a  local  identifier  with  identical 
name),  and  all  inner  modules  that  Import  that  identifier.  If  this  identifier  is  exported  from  the 
module,  its  scope  is  determined  according  to  the  above  definition  as  if  it  has  been  declared 
in  the  body  of  the  containing  module.  If  an  imported  identifier  is  not  declared  or  defined  in 
the  importing  module,  its  scope  within  this  module  is  determined  as  if  it  has  been  declared 
in  the  body  of  the  module;  otherwise,  the  imported  identifier  is  not  known  within  the  module 
body  and  instead,  the  locally  declared  identifier  is  known  there. 


4.8  Programs  and  System  Events 


ine  structure  of  a  program  is  identical  to  that  of  a  module  body.  A  program  can 
be  viewed  as  if  it  is  contained  within  an  implicit  module.  This  module  contains,  in  addition  to 
the  program  itself,  implicit  declarations  of  the  system  event  class  identifiers.  The  system 
routines  that  handle  the  system  events  can  be  considered  as  special  event  handlers 
defined  in  this  implicit  module.  System  events  are  the  mechanism  by  which  a  program 
Interacts  with  the  external  environment.  Possible  examples  of  several  simple  system  event 
class  identifiers  that  one  can  expect  to  find  in  implementations  of  the  language  are: 
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print:  slngle_use  recurrent  event  (int)  ; 

{  print  and  do  not  reply  } 

printc:  single_use  recurrent  event  (int,  tag,  event  (tag))  ; 

{  print,  then  cause  continuation  event  with  given  tag  } 

read:  single_use  recurrent  event  (tag,  event  (int,  tag))  ; 

{  cause  continuation  event  with  read  data,  and  given  tag  } 

tick:  multi_use  non_recurrent  event  (int)  ; 

{  caused  each  tick  of  the  real  time  clock  in  the  system 
with  Increasing  consecutive  numbers  } 

The  system  event  class  identifier  program_start  is  considered  as  part  of  the  language. 
The  system  causes  one  event  from  this  class  when  the  program  is  started.  It  is 
pre-declared  as: 

program_start:  multi_use  recurrent  event  ; 

4.9  Summary 

This  chapter  has  completed  the  definition  of  the  language  by  defining  the 
various  types  of  expressions  in  the  language,  the  scope  rules  for  event  handlers  and 
modules,  and  the  where  clause  predicates.  The  where  clause  predicates  increase  the 
expressive  power  of  the  language  as  shown  fn  chapter  6.  However,  they  somewhat 
complicate  the  implementation  of  the  language  as  discussed  in  chapter  7. 
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5.  Expressive  Power  of  EBL 

The  expressive  power  of  a  language  is  a  measure  that  refers  to  the  ease  with 
which  algorithms  can  be  constructed  in  the  language.  This  measure  is  not  quantitative  and 
is  rather  vague.  The  following  two  chapters  attempt  to  give  the  reader  a  feeling  about  the 
expressive  power  of  EBL.  This  chapter  shows  how  conventional  language  constructs;  such 
as:  goto  statement,  if  statement,  while  statement,  procedures,  functions,  variables, 
assignment  statement,  and  semaphores;  can  be  mapped  onto  EBL.  A  translation  scheme 
from  an  extended  language  XEBL  to  EBL  is  given.  The  purpose  of  this  chapter  is  not  to 
encourage  the  use  of  the  presented  schemes,  but  rather  to  show  that  all  those  constructs 
can  be  modeled  in  a  straightforward  way  and  can  be  used  in  a  systematic  modular  manner  If 
desired. 


The  representation  of  most  of  the  above  conventional  constructs  in  EBL  requires 
a  longer  program  text  in  EBL  than  in  other  languages  which  include  the  constructs  in  their 
repertoire.  The  reason  for  this  is  twofold:  First,  the  absence  of  these  constructs  from  EBL; 
and  second,  the  fact  that  the  constructs  of  EBL  are  rather  primitive.  The  difficulties  that 
one  would  encounter  while  trying  to  express  the  event  mechanisms  of  EBL  in  another 
language  are  probably  greater.  The  next  chapter  tries  to  balance  the  picture  by  giving 
some  examples  that  are  easily  expressed  In  EBL. 

The  following  sections  show  how  each  of  the  above  language  constructs  can  be 
mapped  onto  EBL  when  treated  separately.  In  other  words,  interaction  among  constructs 
(e.g.,  an  If  statement  within  a  while  statement)  is  not  treated.  After  the  presentation  of 


these  basic  schemes  everything  is  put  together  by  a  translation  scheme  from  XEBL  to  EBL. 
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In  the  following  sections  Sj  denotes  an  arbitrary  EBL  script,  and  B  denotes  a  boolean 
expression. 

5.1  Goto  Statement 

If  L  is  a  label  in  the  program,  then  one  possible  way  to  express  the  following 

construct, 

on  <event_handler_heading>  {  <tag_declaration>  } 

(  par_cause  |  seq_cause  }] 

50  ; 

goto  L  ; 

51 

end  ; 

in  EBL  is  as  follows: 

on  <event_handler_heading>  {  <tag_declaration>  } 

{  par_cause  |  seq_cause  }} 

S0  ; 

L  ;  {  cause  a  goto  event  } 

S1 

end  ; 

L:  event  ; 
on  L 
end  ; 

Note  that  if  S-j  is  not  empty  and  the  event  handler  is  a  sequential  handler  then  the  scheme 
actually  presents  a  fork  statement ;  in  order  to  obtain  a  goto  statement,  S-|  should  be 
eliminated.  The  above  method  can  be  extended  to  enable  passing  some  explicit  data  to  the 


target  label  by  adding  parameters  to  L. 
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The  following  construct, 

on  <even._iiandler_heading>  (  <tag_declaratlon>  } 
seq_cause 

50  5 

if  B  then  S-j  else  S2  ; 

S3 

end  i 

can  be  expressed  in  EBL  as  follows: 

on  <event_handler_heading> 

saq_cause 

s0 ; 

if  (B) 

end  ; 

If:  event  (bool)  ; 
endif:  event  ; 

on  If  (b:  bool)  where  b  {  alternative  1  > 

seq_cause 

51  * 
endif 

end  ; 

on  if  (b:  bool)  where  not  b  {  alternative  2  } 
seq_eause 
S2  ; 
endif 

end  ; 

on  endif  {  continue  after  the  If  statement  } 

seq_cause 

s3 

end  ; 


{  <tag_declaration>  } 

{  select  an  alternative  } 
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The  above  scheme  deals  with  sequential  handlers;  the  case  of  parallel  handlers 
Is  even  easier  to  express.  The  scheme  should  be  slightly  modified  if  Sj,  S2,  or  S3  refer  to 
formal  parameters  of  the  containing  event  handler.  In  this  case,  the  values  denoted  by  the 
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formal  parameters  will  be  passed  to  the  two  event  handlers  which  are  activated  by 
occurrences  of  if.  simply  by  adding  the  necessary  parameters  to  the  event  class  identifier 
if.  The  if  statement  translation  scheme  can  be  easily  extended  to  handle  a  case  statement. 
In  the  EBL  subprogram  corresponding  to  a  case  statement  consisting  of  n  alternatives  all  n 
predicates  can  be  evaluated  concurrently. 

5.3  While  Statement 

The  following  construct, 

on  <event_handler_heading>  {  <tag_declaration>  } 

seq_cause 

Sq  ; 

while  B  do  Sj  end  ; 

s2 

end  ; 

can  be  expressed  in  EBL  as  follows: 

on  <event_handler_heading>  (  <tag_declaration>  } 

seq_cause 

Sq  5 

while  (B)  ;  {  activate  the  while  statement  } 

end  ; 

while:  event  (bool)  ; 

on  while  (b:  bool)  where  b  {  entry  to  the  "loop"  } 
seq_cause 

S1  5 

while  (B)  {  another  Iteration  } 

end  ; 

on  while  (b:  bool)  where  not  b  {  continue  on  termination  } 

seq_cause 

s2 


end  ; 
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As  in  the  case  of  the  if  statement,  the  above  scheme  should  be  slightly  modified 
in  order  to  express  parallel  handlers  or  if  formal  parameters  of  the  original  event  handler  are 
referred  to  in  S^  or  S2;  the  same  methods  can  be  applied  here. 

5.4  Procedures 


If  pr  is  a  procedure  name,  then  one  of  the  ways  to  express  in  EBL  the  declaration 
of  the  procedure  pr, 

procedure  pr  (  (  <foriral_parameter_list>  ) 

{  <tag_declaration>  ) 


do 


S0  ; 

return 


end  ; 

Is  as  follows: 

epr:  event  (event  (tag),  tag  {  ,  <type_list>  )  ; 

on  epr  (c:  event  (tag),  t:  tag  {  ,  <formal_parameter_list>  ) 

{  <tag_declaration>  } 

{  par_cause  |  seq_cause  }] 

Sq  ; 

c  (t)  {  signal  procedure  termination  } 

end  : 


The  following  procedure  call, 

on  <event_handler_heading>  (  <tag_declaratlon>  } 

seq_cause 

S1  ; 

call  pr  (  (  <actual_parameter>  {  ,  <actual_parameter>  }  )  } '  ; 

s2 

end  ; 


will  now  be  expressed  as: 
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con:  event  (tag)  ;  {  continuation  event  } 

jpr:  event  (tag,  ...  )  ;  {  for  passing  state  to  continuation  point  } 

on  <event_handler_heading>  {  <tag_declaration>  } 

tpr:  tag  ;  {  declare  a  unique  tag  for  this  call  } 

seq_cause 

Sl  i 

epr  (con,  tpr  {  ,  <actual_parameter>  (  ,  <actual_parameter>  }  ) 

{  call  pr  >  ; 

Jpr  (tpr,  ...  )  {to  join  the  continuation  point  } 

end  ; 

on  con  (tl:  tag)  a  jpr  (t2:  tag,  ...  )  where  t1=t2  {  when  result  arrives  } 

seq  cause 

s2 

and  ; 

The  above  scheme  for  mapping  procedure  calls  allows  recursive  procedure  calls, 
and  concurrent  activations  of  the  same  procedure.  It  uses  continuations  as  the  mechanism 
for  "returning"  from  the  procedure  call.  The  scheme  allows  passing  state  information  to  the 
continuation  point  by  communicating  to  that  point  an  event  from  the  class  jpr.  The  scheme 
uses  tag  parameters  for  distinguishing  between  different  calls  to  the  procedure.  A  tag 
Identifier  Is  declared  within  the  event  handler  containing  the  procedure  call.  For  every 
Instance  of  the  event  handler  which  invokes  the  procedure,  the  (local)  tag  identifier 
assumes  a  unique  value;  thus,  no  ambiguity  occurs  on  joining  the  results  at  the  continuation 
point.  Therefore,  recursive  procedures  and  concurrent  activations  of  procedures  can  be 
used.  In  procedures  that  do  not  require  all  the  above  features,  the  mechanism  can  be 
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5.5  Functions 

In  order  to  express  a  function  in  which  the  return  statement  has  an  argument 
specifying  a  value  to  be  returned  as  the  function  result,  only  slight  modifications  are  needed 
in  the  scheme  for  expressing  procedures  described  above.  The  first  parameter  of  the 
event  class  identifier  epr  will  include  in  its  type  list  in  addition  to  a  tag  parameter  also  the 
result  parameter.  The  event  c(t)  in  the  script  of  the  function  definition  will  be  modified  to 
c(t,  ...)  where  the  dots  represent  the  returned  expression.  Some  other  trivial  modifications 
resulting  from  the  above  changes  need  to  be  done.  The  scheme  proposed  here  can  be 
easily  extended  to  express  a  function  returning  several  values. 

5.6  Variables 

EBL  has  no  conventional  variables  and  no  assignment  statement.  Despite  this 
fact,  both  of  those  can  be  easily  mapped  onto  EBL  and  the  effect  of  mutable  objects  can  be 
achieved.  This  chapter  shows  how  variables  can  be  modeled  through  the  use  of  single_use 
events.  The  next  chapter  includes  an  example  (the  readers  writers  problem)  showing  how 
multi_use  events  can  be  used  to  model  the  effect  of  mutable  objects.  This  section  deals 
with  references  to  variables  and  the  next  section  with  assigning  values  to  variables. 
single_use  events  can  be  used  to  "store"  the  variables'  values.  In  the  following 
declarations  of  variables, 

v:  <basic_type>  ; 

rv:  record  (  <field_list>  )  ; 

av:  array  [  <indox_range>  (  ,  <index_range>  }  ]  of  <basic_type>  ; 
the  syntax  of  <field_list>  is  similar  to  that  of  <formal_parameter_list>,  with  the  only 
difference  that  a  field  must  be  of  basic  type;  and  the  syntax  of  <index_range>  is 
<constant>  ..  <constant>.  The  declarations  will  be  replaced  by: 
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ev:  event  (  <basic_type>  )  , 

erv:  event  (  <basic_type>  (  ,  <basic_type>  }  )  ; 

eav:  event  (  int  {  ,  Int  }  ,  <basic_type>  )  ; 

on  program_start 

{  par_cau se  |  seq_cause  )  ] 

ev  (...)  {  some  initial  value  of  basic  type  }  ; 

erv  (...)  {  some  initial  value  for  every  field  }  ; 

{  For  each  element  of  the  array  av,  cause  an  event  from  the  event 
class  eav.  Cause  ail  elements  of  the  array,  either 
explicitly  or  use  the  while  statement  scheme  } 

end  ; 


Each  conventional  simple  variable  (a  variable  of  a  basic  type),  record  variable,  or 
array  is  represented  by  an  event  class  identifier  of  a  single_use  type.  Exactly  one  event 
from  every  class  is  caused  (one  event  object  is  created)  initially  for  every  simple  variable, 
record  variable,  or  array  element.  The  parameters  have  some  default  values  according  to 
their  types,  or  according  to  the  values  to  which  the  variables  were  to  be  initialized.  For 
convenience  the  name  selected  for  each  event  class  identifier  is  obtained  by  adding  the 
character  "e"  to  the  variable's  name;  thus,  keeping  the  original  name  for  a  later  use,  as  will 
be  shown  shortly. 

Now  the  way  to  reference  variables  is  examined,  starting  with  references  to 
variables  of  a  basic  type  in  expressions.  The  idea  is  simple:  if  several  variables  appear  in 
an  expression,  the  modified  names  of  those  variables  are  included  in  the  heading  of  the 
event  handler  containing  the  expression;  thus,  the  current  values  of  those  variables  are 
read  (and  destroyed)  w.ien  the  Instance  of  the  event  handler  is  activated,  and  then 
restored  when  the  script  is  executed.  Assume  that  a,  b,  ...  ,  z  are  the  names  of  the 
variables  Included  in  an  expression  <exp>,  then  the  following  construct, 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BURLAU  OF  STANDARDS  1963 -A 


■.■:■■.  ■  .....  -r--- •"  •  '•••  5KyWl'*r' 


-96- 


Section  6.6 


Variables 


on  <event_descriptor_list>  (  where  < condition) 
{  <tag_declaration>  } 

{  par_cause  |  seq_cause  }] 


S 


1  5 


{  a  statement  containing  <exp>  }  ; 


end  ; 


s2 


will  be  represented  as: 

on  <event_descriptor_list>  a 

ea  (a:  <basic_type>  )  a  ...  a  ez  (z:  <baslc_type>  ) 
{  where  <condition>  J1 
{  <tag_declaratk>n>  } 

{  par  cause  |  seq_cause  }\ 

S1  • 

ea  (a)  ;  {  restore  tt  e  variable  } 


ez  (z)  ;  {  restore  the  variable  > 

{  a  statement  containing  <exp>  }  ; 

s2 

and  ; 

In  the  above  scheme,  the  expression  Itself  Is  written  unchanged  (as  a  result  of 
the  selected  naming  scheme).  Of  course,  naming  conflicts  should  be  resolved,  but  this  is  a 
trivial  problem. 

In  order  to  refer  to  the  field  fl  of  record  variable  rv  in  an  expression,  the 
following  event  descriptor, 

erv  (  ... ,  fl:  <baslc_type>  , ...  ) 

can  be  included  in  the  heading.  In  addition,  the  following  event, 

erv  (  ... ,  fl, ...  )  :  {  restore  the  record  variable  } 

is  added  to  the  script  of  the  event  handler.  In  order  to  refer  to  soma  array  element  In  an 


1,  . 


expression,  e.g., 
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av  [  <lndex>i  , ... ,  <lndax>n  ] 

where  <index>  Is  an  integer  expression,  the  modified  names  of  all  variables  appearing  In 
Indexes  of  the  array  are  simply  Included  In  the  heading  of  the  event  handler;  In  addttlon,  an 
event  descriptor  for  the  array  element  Itself  is  added  and  the  where  clause  is  modified. 
The  added  event  descriptor  Is. 

eav  Gi . in:  Int,  av:  <basic_type>  ) 

and  the  following  clause  Is  appended  to  the  boolean  expression  in  the  where  clause: 

and  (l1  *  <index>i  and  ...  anti  in  -  <index>n) 

The  script  will  include  the  event: 

eav  (lj, ... ,  in,  av)  ;  {  restore  the  array  element  } 

Function  calls  within  expressions  in  some  statement  S,  can  be  moved  to 
assignment  statements  before  S  such  that  each  assignment  statement  in  the  (modified) 
program  contains  at  most  one  function  call,  which  is  at  the  outermost  level  of  the 
expression.  The  section  on  assignment  statement  deals  with  this  case. 

6.7  Assignment  Statement 

Since  one  event  object  carries  the  current  value  associated  with  e  simple 
variable,  the  current  record  associated  with  a  record  variable,  or  the  current  value 
associated  with  an  array  element,  the  assignment  consists  of  destroying  the  current  event 
object  (variable  object)  and  creating  a  new  one.  Thus,  the  effect  of  mutable  objects  Is 
achieved  by  destroying  the  current  objects  and  creating  updated  ones.  First,  consider  the 
case  in  which  the  right  hand  side  of  the  assignment  statement  does  not  contain  a  function 
call.  This  case  is  further  subdivided  according  to  the  left  hand  side  of  the  assignment 
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statement  which  can  be  a  simple  variable,  a  record  variable  component  (e.g.,  rv.fl),  or  an 
array  element.  Assignment  to  the  simple  variable  v, 

on  <event_han<Ner_headlng>  (  <tag_declaratlon>  } 

{  par  causa  |  sag  cause 

“S,  ; 

V  :■  <exp>  ; 

«2 


where  <exp>  refers  to  variables  a,  b, ... ,  z  will  be  represented  as: 

on  <event_handler_haading>  (  <tag_declaration>  } 

{  par_cause  |  seq_cause  }] 

*1  5 

L  {  goto  the  assignment  handler  } 


{  event  for  activating  the  assignment  handler  } 


on  L  a  ev  (v:  <baslc_type>  )  a  {  the  assignment  handler  > 

ea  (a:  <basic_type>  )  a  ...  a  az  (z:  <baslc_type>  ) 
{  par_cause  |  seq_eausa  }J 

ea  (a)  ;  {  restore  the  variable  } 


{  restore  the  variable  } 

{  assign  new  value  to  v  } 


ez  (z)  ; 

ev  (  <axp>  )  ; 

So 


Assignment  to  record  variables  and  array  elements  can  be  expressed  in  a  similar  fashion. 
Parallel  assignments  to  several  fields  of  a  record  variable  can  be  easily  achieved  by 
changing  more  than  one  parameter  in  the  event  that  assigns  the  new  record  to  the  record 
variable.  In  fact,  using  this  Idea  one  can  implement  several  conventional  variables  as 
distinct  fields  In  a  newly  created  record  variable  and  then  have  an  atomic  parmltml 
assignment  to  several  variables. 
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As  stated  previously,  the  program  can  be  modified  such  thet  each  assignment 
statement  contains  at  most  one  function  call  (which  is  at  the  outermost  level  of  the 
expression  on  the  right  hand  side).  The  cases  in  which  the  right  hand  side  of  the 
assignment  statement  is  such  a  function  call  are  dealt  with  by  combining  the  scheme 
presented  in  the  section  on  functions  with  the  scheme  presented  above. 


6.8  Semaphores 


This  section  shows  how  operations  on  senapho.o  varirbles  can  be  expressed  in 
EBL.  A  general  semaphore  variable  can  be  Implemented  as  an  event  class  Identifier  of  a 
slngle_use  recurrent  type.  The  declaration  of  semaphore  variable  s. 


a:  semaphore  ; 


is  replaced  by: 


The  V  operation. 


Is  replaced  by: 


V(s); 


The  P  operation  in  the  following  event  hanger, 

on  <event_handler_heading>  {  <tag_declaratton>  ) 


«1i 

P(S); 


is  replaced  as  follows: 
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on  <event_handlerheading>  (  <tag_deciaration>  } 

seq  CMte 

S,  ; 

L  {  activate  the  P  handler  } 

end  ; 

L:  event  {  event  for  activating  the  P  handler  } 

on  L  a  es  {  the  P  handler  } 

seq_ceuse 

s2 

end  ; 


General  semaphore  variables  are  often  used  to  control  the  allocation  of  identical 
resources  (e.g.,  printers).  The  ability  to  attach  parameters  to  semaphores  In  EBL  greatly 
simplifies  the  allocation  of  such  resources,  since  the  waiting  process  can  get  some 
information  on  the  specific  allocated  resource  (e.g.,  Its  logical  number)  when  it  is  allowed  to 
proceed.  Multiple  P  operations  [DI-71 ,  Pa-71]  can  be  easily  expressed  in  the  language. 
The  P  handler  above  is  written  as: 

on  L  a  es]  a  ...  a  esn  {  the  multiple  P  handler  } 

seq_causa 


The  desired  semantics  is  achieved  since  the  activation  of  an  instance  of  an  event  handler  Is 
an  atomic  action.  An  example  of  the  use  of  the  multiple  P  operation,  the  five  dining 
philosophers,  is  given  In  the  next  chapter. 

Earlier  It  was  shown  how  conventional  variables  can  be  mapped  onto  EBL  by  using 
event  class  Identifiers  of  a  single_usa  recurrent  type.  In  the  scheme  proposed  there,  a 
reference  to  a  variable  has  been  always  replaced  by  en  event  descriptor  In  the  event 
handler  heading,  and  a  restoring  event  in  the  script.  These  operations  are  actually  P  and  V 
operations;  therefore,  In  many  cases  no  additional  synchronization  operations  are  needed. 
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One  can  think  at  that  scheme  as  waiting  for  the  varlablea  to  be  accessible,  using  them,  and 
freeing  them  when  the  operation  is  done. 

6.9  Extensions  to  EBL 

Each  of  the  previous  sections  In  this  chapter  treated  separately  one 
conventional  language  construct.  The  rest  of  this  chapter  demonstrates  how  a  program 
containing  many  of  these  constructs  can  be  translated  to  EBL.  The  following  section 
describes  several  extensions  to  EBL,  resulting  in  an  extended  language  XEBL.  XEBL  is  not 
proposed  as  an  Improvement  to  EBL,  but  as  a  concrete  example  for  demonstrating  that  such 
a  translation  is  feasible.  The  remaining  sections  outline  an  algorithm  for  translating  a 
program  from  XEBL  to  EBL.  The  translation  is  done  in  two  phases:  a  translation  from  XEBL  to 
its  kernel,  and  a  translation  from  this  kernel  to  EBL. 

6.9.1  Extended  EBL 

This  section  does  not  Intend  to  give  a  precise  definition  of  XEBL.  A  general 
description  of  vthe  language  is  sufficient  for  the  following  discussion.  In  EBL  the  only  kind  of 
a  program  unit  is  an  event  handler.  In  XEBL  a  program  unit  can  be  an  event  handler,  a 
procedure,  or  a  function.  Program  units  cannot  contain  one  another;  however,  they  can  be 
contained  in  modules.  The  structure  of  a  program  unit  Is  similar  to  that  of  an  event  hamfter. 
The  body  of  a  program  unit  contains  (optional)  tag  declarations  and  a  script. 

A  script  is  a  Rat  of  statements.  There  are  simple  statements  and  compound 
statements;  a  compound  statement  is  a  sequence  of  simple  statements  delimited  by 
statement  brackets.  The  possible  simple  statements  are:  cause  statement  (whose  structure 
is  cause  <event>),  goto  statement,  if  statement,  while  statement,  procedure  cad. 
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assignment  statement,  P  operation,  and  V  operation.  Statements  can  contain  other 
statements,  like  In  block  structured  languages;  those  which  are  not  contained  in  other 
statements  are  of  level  zero.  Like  in  EBL,  a  script  can  be  either  parallel  or  sequential.  In  the 
first  case  execution  of  the  statements  of  level  zero  Is  not  ordered  (in  this  case  the  script 
contains  several  parallel  script  branches),  and  in  the  latter  case  It  is  ordered  (in  this  case 
the  script  contains  one  script  branch).  The  execution  of  a  script  branch  Is  always 
sequential,  even  In  case  of  a  parallel  script 

The  target  of  a  goto  statement  (the  label)  must  be  In  the  script  containing  the 
goto  statement.  A  goto  statement  In  one  branch  of  a  parallel  script  cannot  specify  as  its 
target  a  label  within  another  branch  of  that  script.  There  are  simple  variables  (variables  of 
basic  types),  record  variables,  and  array  variables.  Variable  declarations  cannot  appear 
within  program  units.  Variables  and  function  calls  can  appear  in  any  expression  except  In 
event  handler  headings. 

6.9.2  Translation  from  XEBL  to  its  Kamel 

The  main  three  steps  In  the  transformation  of  a  program  from  XEBL  to  Its  kernel 
are  discussed  now.  First,  every  while  statement  Is  transformed  to  an  equivalent  statement 
sequence  which  uses  an  If  statement  and  goto  statements.  Second,  function  calls  In  actual 
parameters  of  cause  statements,  procedure  calls,  and  function  calls  are  eliminated.  This  Is 
done  by  adding  appropriate  assignment  statements  before  the  original  statements,  and 
declaring  new  variables  as  necessary.  Third,  every  assignment  statement  Is  transformed  to 
an  equivalent  sequence  of  assignment  statements.  The  left  hand  side  of  each  assignment 
statement  contains  no  function  cads  (In  array  Indexes),  and  the  right  hand  side  contains  at 
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moat  ons  function  call  (which  Is  at  the  outermost  level  of  the  expression). 

The  transformations  are  done  In  a  way  which  preserves  the  various  script 
branches  in  each  script.  This  Is  achieved  by  adding  statement  brackets  as  necessary. 

5.9.3  Translation  from  the  Kernel  to  EBL 

The  algorithm  for  translating  a  program  from  the  Kernel  of  XEBL  to  EBL  is  outlined 
in  this  section. 

1.  Replace  every  variable  declaration  by  an  appropriate  event  class  Identifier 
declaration.  Add  event  handlers  for  causing  initial  events  from  these  event 
classes.  This  initialization  is  triggered  by  the  initial  event  program_start.  In  case 
of  array  variables,  perform  the  Initialization  by  using  the  translation  scheme  for  a 
while  statement  presented  earlier  in  this  chapter. 

2.  Transform  every  procedure  or  function  declaration  to  an  event  handler.  At  this 
step  only  transform  the  headings  and  create  a  new  event  class  identifier  for 
each  procedure.  The  script  is  handled  in  other  steps  of  this  algorithm. 

3.  Split  every  statement  containing  a  function  call  into  two  statements:  a  function 
call  (identical  to  a  procedure  call),  and  a  special  assignment  statement  whose 
right  hand  side  is  f  unctlon_retum. 

4.  Find  the  basic  blocks  in  each  script  and  build  a  flow  graph  [Ah-77].  A  basic  block 
starts  on:  (1 )  the  beginning  of  each  script  branch;  (2)  each  labeled  statement 
which  Is  the  target  of  at  least  one  goto  statement;  (3)  the  beginning  of  each  arm 
In  an  if  statement;  (4)  each  P  operation;  (6)  each  statement  Immediately 
following  the  end  of  a  basic  block  (as  defined  next)  in  a  sequence  of  statements. 


T,  . 

r 


*  / 


Translation  from  ths  Kamel  to  EBL  -  1 03  -  Section  6.9.3 

A  basic  block  ends  in  the  following  cases:  (1)  after  the  last  statement 
In  each  script  branch;  (2)  after  each  goto  statement;  (3)  after  the  test  in  each  if 
statement;  (4)  after  each  procedure  or  function  call;  (5)  after  each  statement 
Immediately  preceding  the  beginning  of  a  basic  block  (as  defined  earlier)  in  a 
sequence  of  statements. 

6.  Attach  a  unique  label  L  to  the  beginning  of  each  basic  block  B  (if  needed).  Add 
goto  statements  at  the  end  of  basic  blocks  leading  to  B  (according  to  the  flow 
graph),  except  in  basic  blocks  which  terminate  by  a  goto  statement,  a  procedure 
call,  or  a  function  call.  In  a  block  leading  to  B,  which  ends  with  a  procedure  call 
or  a  function  call,  L  will  be  used  as  a  continuation  in  the  event  replacing  the  call. 

6.  For  each  basic  block  B  (except  in  the  cases  defined  next)  whose  first  statement 
is  labeled  by  a  label  L,  create  a  new  event  handler  whose  event  descriptor  list 
contains  L.  The  exceptions  are:  (1)B  is  the  first  basic  block  in  a  sequential 
script;  (2)  B  contains  exactly  one  statement,  a  cause  statement,  a  goto 
statement,  or  a  V  operation,  and  It  corresponds  to  a  complete  script  branch  in  a 
parallel  script. 

7.  In  a  parallel  script,  for  each  script  branch  which  was  transformed  to  at  least  one 
event  handler  (in  the  previous  step)  replace  the  script  branch  by  a  goto 
statement.  This  goto  statement  is  In  fact  a  fork  statement;  its  target  is  the 
event  handler  corresponding  to  the  first  basic  block  in  the  script  branch. 

8.  At  this  stage  the  program  is  In  a  form  which  Is  suitable  for  a  simple  application  of 
the  translation  schemes  for  each  of  the  constructs  as  discussed  earlier  in  this 
chapter.  First,  references  to  variables  appearing  in  expressions  and  assignment 
statements  are  dealt  with.  The  structure  of  cause  statements  is  modified 
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according  to  the  syntax  of  EBL  (elimination  of  the  keyword  cause).  Then, 
procedure  calls,  function  calls,  and  returns  from  procedures  and  functions  are 
treated.  At  this  stage,  goto  statements  and  If  statements  can  only  appear  at  the 
end  of  a  script  branch.  Moreover,  an  If  statement  has  the  restricted  form*. 

if  <bod_exp>  then  goto  <label>i  {  else  goto  <label>2  }  ; 

The  translation  scheme  for  goto  statements  and  if  statements  can  be  applied. 

The  translation  algorithm  generates  new  Identifiers  in  various  steps.  We  assume 
the  existence  of  some  simple  mechanism  for  generating  unique  identifiers.  Note  that  formal 
parameters  of  a  program  unit  in  XEBL  can  be  referenced  in  statements  which  move  to  new 
event  handlers  In  the  translation  process.  The  referenced  parameters  should  be  passed  to 
these  event  handlers  by  the  activating  events. 

6.10  Summary 

The  language  does  not  contain  conventional  constructs  such  as:  variables, 
assignment  statement,  goto  statement,  iteration  constructs,  procedures,  functions,  and 
semaphores.  The  reason  is  that  these  constructs  can  be  easily  modeled  in  the  language.  A 
scheme  for  systematically  translating  a  program  containing  these  constructs  to  EBL  has 
been  developed  in  this  chapter. 
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6.  Classical  Examples 


This  chapter  shows  how  some  classical  problems  can  be  solved  in  terms  of  E Bl¬ 
its  purpose  Is  twofold:  first,  to  show  the  ease  of  expressing  the  solutions,  and  more 
important,  to  lead  through  each  example  to  some  interesting  observations  on  the  language. 


6.1  "Recursive"  Linear  Fibonacci 


This  section  demonstrates  one  of  the  possible  applications  of  multi_use 

non_recurrent  events,  computing  functions  by  tables,  by  presenting  a  subprogram  for 

computing  fibonacci(n).  (A  similar  solution  appears  in  [Ko-79].)  If  the  event  F(n)  is  caused, 

the  handlers  cause  RF(n,s),  where  n  is  the  original  argument,  and  s  is  equal  to  fibonacci(n). 

F,  JF:  multi_use  nonrecurrent  event  (Int)  ; 

RF:  multi_u*e  non_recurrent  event  (Int,  Int)  ; 

on  F  (n:  Int)  where  n=0  or  n=1  {  basis  } 

par_cause  RF  (n,  n) 
end  -, 

on  F  (n:  Int)  where  n>1 
par  cause 

F (n-1)  ; 

F (n-2)  ; 

JF  (n) 

end ; 

{  the  joining  event  handler  } 
on  JF  (n:  Int)  a  RF  (nl ,  si :  Int)  a  RF  (n2,  s2:  int) 

where  nl =n-1  and  n2*n-2 
par_cause  RF  (n,  si  +s2)  {  add  the  two  subresults  } 

end  ; 


{  Induction  step  } 


{  for  joining  the  results  } 


The  above  handlers  can  be  used  as  follows: 


L:  event  (int)  ;  {  for  activating  the  continuation  handler  } 

{  the  continuation  handler  } 
on  L  (nl:  int)  a  RF  (n,  a:  int)  where  n1=n 

...  {  use  the  result  } 

end  ; 

The  structure  of  the  program  brings  to  mind  the  known  recursive  implementation 
of  the  function  but  the  semantics  of  EBL's  events  causes  a  unique  behavior.  Since 
mu!ti_use  non_recurrent  events  are  employed,  for  each  n  at  most  one  event  of  the  form 
F(n)  can  exist  and  once  such  event  is  caused  it  remains  forever.  Thus,  for  each  n  at  most 
one  of  the  first  two  handlers  Is  activated  since  their  activating  conditions  are  mutually 
exclusive.  For  each  n  the  joining  event  handler  Is  activated  at  most  once.  This  can  be 
proved  by  showing  that  for  each  n  the  following  properties  hold: 

PI .  There  is  at  most  one  event  of  the  form  JF(n). 

P2.  There  is  at  most  one  event  of  the  form  RF(n-1,s1). 

P3.  There  is  at  most  one  event  of  the  form  RF(n-2,s2). 

Property  PI  holds  since  JF  Is  a  multi_use  non_recurrent  event  class  identifier. 
Properties  P2  and  P3  can  be  shown  by  proving  that: 

P4.  For  each  n  at  most  one  event  of  the  from  RF(n,s)  exists. 

Property  P4  can  be  proved  by  induction  on  n.  One  consequence  of  property  P4  is  that  no 
two  different  results  can  be  returned  by  the  above  program  for  the  same  n. 

I  . 
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Since  the  joining  event  handler  is  activated  at  most  onco  for  each  n,  the  normal 
exponential  behavior  of  a  recursive  implementation  of  the  fibonacci  function  is  not 
manifested  here.  In  fact,  after  RF(n,s)  Is  caused  (i.e.,  after  the  computation  of  fibonacci(n) 
has  been  completed)  the  results  of  fibonacci(i)  for  all  0<i<n  are  remembered  forever  and 
there  is  no  need  to  compute  them  again.  Note  that  the  "table"  Is  empty  when  the  program 
is  started,  and  is  gradually  built  as  the  computation  proceeds. 

The  number  of  events  caused  when  computing  flbonacci(n)  is  at  most  linear  in  n, 
and  in  many  cases  is  just  one  event,  L(i).  Clearly,  we  only  see  here  a  time  space  tradeoff;  a 
faster  response  is  achieved  at  the  expense  of  storing  the  results.  Each  time  a 
non_recurrent  event  is  caused,  the  conceptual  list  of  events  from  that  class  has  to  be 
searched  in  some  form  or  another  and  the  search  time  is  a  function  of  the  size  of  the  list.  In 
order  to  activate  the  continuation  event  handler,  the  conceptual  list  of  results  (events  of 
class  RF)  hes  to  be  searched.  The  above  searches  can  be  done  in  linear  time,  or,  if  the 
compiler  is  smart  and  implements  the  event  lists  In  some  efficient  structure,  in  less  than 
linear  time;  if  sufficient  storage  Is  allocated  the  searches  can  be  done  in  a  constant  number 
of  operations.  In  summary,  this  example  shows  how  computing  functions  by  tables  can  be 
easily  expressed  in  the  language. 

6.2  The  Readers  Writers  Problem 

The  problem  of  readers  and  writers  was  suggested  originally  in  [Co-71]  and  then 
considered  in  many  papers  dealing  with  synchronization  mechanisms;  e.g.,  [Ho-74,  Gr-75]. 
We  could  not  resist  the  temptation  to  try  to  solve  the  problem  in  terms  of  EBL,  and  this  led 
to  some  interesting  observations.  The  first  question  was  whether  the  problem  can  even  be 
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stated  In  terms  of  EBL  event  mechanisms.  The  problem  Involves  sharing  e  database  among 
readers  and  writers,  and  it  is  not  clear  at  all  how  to  model  it  in  EBL  The  only  scheme  so  far 
presented  for  creating  the  effect  of  mutable  objects  relies  on  slngle_use  events;  however, 
if  such  a  solution  is  adopted  he  e  then  there  is  no  concurrency  at  all  even  among  readers. 
The  reason  is  that  the  only  way  a  reader  can  read  a  single_use  event  is  by  using  It;  after 
doing  so,  the  event  disappears  and  the  reader  has  to  recreate  the  event  object  before 
another  reader  can  access  it. 


Surprisingly  enough,  multl_use  recurrent  events  can  model  the  desired  behavior 

of  a  database.  Let  us  assume  the  database  consists  of  an  array  of  records;  the  array  will 

be  represented  by  an  event  class  Identifier  of  an  appropriate  multl_use  recurrent  type. 

The  sharing  of  data  among  readers  can  be  achieved  if  each  reader  always  ret,ds  the  "latest 

version"  of  the  appropriate  object;  !.e.,  by  using  the  predicate  last  of  EBL.  A  writer  modifies 

an  item  in  the  database  simply  by  causing  an  event  from  that  class.  The  subprograms  for 

the  writers  and  the  readers  for  this  case  are  shown  below: 

db:  multi_use  recurrent  event  (int, ...  )  ;  {  database.  The  first  parameter 
is  the  array  index,  the  following  are  the  record  fields  } 
read:  event  (Int)  ;  {  for  activating  the  reader  handler. 

The  parameter  specifies  an  array  index  } 


WRITER: 


on 


db  (Index, ... ) 


end  s 


{  write  a  record  } 
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READER: 


on  read  (ind:  int)  a  db  (index-.  Int, ...  )  where  (ind*index)  a  last  (db) 
•  •  • 

...  {  use  the  read  record  fields  } 


end  ; 

Notice  that  reading  by  a  reader  has  no  effect  on  the  database.  Also,  no  special 
synchronization  Is  required  among  writers;  a  writer  writes  whenever  it  wants.  The  action  of 
writing  a  record  by  a  writer  can  be  viewed  as  atomic  (as  defined  for  example  in  [Re-78]) 
since  there  is  a  point  in  time  before  which  the  new  record  Is  not  yet  written  and  after  which 
It  is  written.  This  point  (corresponding  to  the  commit  point  of  an  atomic  action)  is  the  time  at 
which  the  event  is  caused  (the  corresponding  event  object  Is  inserted  into  the  conceptual 
event  list)  and  thus  becomes  the  last  existing  event. 


Let  us  examine  the  properties  of  the  above  solution  (i.e.,  what  problem  does  it 
solve?).  This  is  clearly  a  restricted  version  of  the  known  versions  of  the  problem  since  the 
database  consists  of  disjoint  objects  (array  records).  Other  restrictions  stem  from  the  fact 
that  no  mutual  exclusion  is  used.  A  writer  can  write  several  records  but  each  write 
operation  is  a  separate  atomic  action;  it  cannot  write  several  records  in  one  atomic  action. 
Thus,  the  maximal  consistent  unit  of  information  in  this  scheme  is  an  array  record;  this  is  the 
reason  why  a  reader  reads  only  one  record  in  each  read  operation  in  the  above  scheme. 
Another  limitation  is  that  a  writer  cannot  read  any  information  of  the  database  and  perform  a 
write  operation  all  in  one  atomic  action. 

The  restrictions  of  the  above  scheme  cannot  be  ignored.  However,  there  are 
applications  for  which  those  restrictions  are  not  applicable.  More  importantly,  the  solution 
has  the  following  interesting  properties:  it  is  extremely  simple,  readers  and  writers  can 
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coexist  (i.e,,  maximal  concurrency  Is  obtained),  and  the  delay  associated  with  a  read  or 
write  operation  is  minimal.  Note  that  If  all  references  to  the  database  In  a  program  use  the 
above  scheme  (In  particular  the  predicate  last),  a  clever  compiler  can  decide  to  implement 
the  database  as  an  array,  or  some  similar  data  structure,  without  keeping  +he  whole  history 
of  the  database  (as  implied  by  the  definition  of  multl_use  events). 


The  next  question  Is:  can  the  above  approach  be  extended  to  a  less  restricted 
version  of  the  problem?  The  answer  Is  positive;  consider  now  the  case  in  which  the  maximal 
consistent  unit  of  information  read  by  a  reader  is  an  array  record  (as  In  the  previous 
version).  However,  a  writer  can  also  read  several  records  when  entering  the  database  and 
leave  the  database  consistent  after  modifying  several  records;  i.e.,  a  writer  can  read  and 
modify  several  records  In  an  atomic  action.  The  trick  here  is  to  create  two  databases:  one, 
for  the  readers,  identical  to  that  of  the  previous  version,  and  the  second,  for  the  writers, 
consisting  of  slngle_use  events  which  carry  the  data  and  provide  (only  the  necessary) 
mutual  exclusion  among  the  writers. 

rdb:  multi_use  recurrent  event  (Int, ...  )  ;  {  readers  database.  The  first 

parameter  is  the  array  index,  the  following  are  the  record  fields  } 
wdb:  single_use  recurrent  event  (int,  ...);{  writers  database. 

The  parameters  are  as  in  rdb  } 

read:  event  (Int)  ;  {  for  activating  the  reader  handler. 

The  parameter  specifies  an  array  Index  } 
write:  event  (...);  {  for  activating  the  writer  handler  specifying 

which  records  to  modify  } 


WRITER; 


on  write  (...)  a  wdb  (...)  a  ...  a  wdb  (  ...  )  where  B 

{  B  selects  the  needed  records  of  the  array  wdb  ) 

seq_cause 

rdb  (...);...;  rdb  (...);  {  first,  modify  readers  database  } 

wdb  wdb  (...)  {  next,  update  writers  database  } 

end  ; 


*  + 


■lluqee 

,£_Z 


The  Readers  Writers  Problem 


READER: 


-  Ill 


Section  0.2 


on  read  (ind:  int)  a  rdb  (Index:  Int, ... )  where  (lnd*index)  a  last  (rdb) 

*  *  • 

...  { use  the  read  record  fields ) 

*  end  ; 

f 

The  correctness  of  this  scheme  can  be  easily  understood  by  observing  that  It  basically  uses 
the  two  phase  lock  protocol  described  In  [Gr-78].  This  solution  is  still  simple  in  comparison 
f  to  the  known  solutions  to  the  various  versions  of  the  problem.  It  provides  a  minimal  delay  for 

readers,  which  can  coexist  with  writers;  and  allows  several  writers  to  coexist  If  they 
access  mutually  exclusive  records  of  the  database. 


* 

i 
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Note  that  the  schemes  presented  above  can  be  modified  in  several  ways.  For 
example,  in  order  to  decrease  space  overhead  wdb  can  carry  only  an  index  parameter  and 
not  the  data  itself;  i.e.,  act  as  a  semaphore  array.  Also  note  that  the  known  solutions  to  the 
various  versions  of  the  problem  can  be  translated  to  EBL;  we  shall  not  do  so  since  it  does 
not  provide  any  deeper  insight. 

6.3  Airline  Reservation  System 

This  section  contains  an  example  of  a  simplified  airline  reservation  system.  The 
system  handles  concurrently  several  flights,  each  of  100  seats,  and  recognizes  several 
requests:  Info,  which  returns  the  current  number  of  available  seats  In  flight  number  f; 
reservo,  which  reserves  n  seats  in  flight  number  f;  cancel,  which  cancels  reservation  of  n 
seats  in  flight  number  f;  and  Inlt,  the  Initial  command  specifying  the  number  of  flights  in  the 
system.  Some  of  the  requests  expect  an  answer  and  this  is  achieved  by  passing  a 
continuation  event  class  identifier  as  a  parameter  In  the  requesting  event. 
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modulo  {  for  airline  reservations  > 

export:  info,  reserve,  cancel,  init ; 

intp  ■■  int,  Int ;  {  integer  pair  type  identifier} 

ct  >■  event  (Intp,  bool)  ;  {  continuation  type  identifier  } 

info:  event  (int,  event  (intp))  ; 

reserve:  event  (intp,  ct)  ; 

cancel,  ent:  event  (intp) ; 

init:  event  (Int)  ; 

on  info  (f :  Int,  c:  event  (Int,  Int))  a  ent  (fl,  i:  Int)  where  f*fi 
par_cause 

ent  (fl,  I)  ;  {do  not  modify  the  counter  } 

c  (fl,  I)  {  send  the  reply  } 

end ; 


on  reserve  (f,  n:  Int,  c:  ct)  a  ent  (fl,  i:  Int)  where  f*fl  and  l>«n 
par_ceuse 

ent  (fl,  i-n)  ;  {  decrement  the  counter  } 

c  (f,  n,  true)  {  positive  reply  } 

end  ; 


on  reserve  (f,  n:  int,  c:  ct)  a  ent  (fl,  I:  Int)  where  f*f1  and  Kn 

par_ceuse 

ent  (fl,  I)  ;  {  do  not  modify  the  counter  } 

c  (f,  n,  false)  {  negative  reply  } 

end  ; 


on  cancel  (f,  n:  int)  a  ent  (fl,  I:  Int)  where  f*ft 
par_causa 

ent  (fl,  i+n)  {  Increment  the  counter  } 

end  ; 


on  Init  (n:  Int)  where  n>0 
par_cause 

init  (n-1)  ; 
ent  (n,  1 00) 

end  ; 

end ; 


{  iterate  } 

{100  seats  for  each  'light  } 

{  of  airline  reaarvatfon  module  } 


A  counter  is  associated  with  each  flight;  this  counter  Is  an  event  from  the  dess 
ent.  Each  of  the  counters  also  provides  for  mutual  exclusion  among  concu-rent  requests  for 
accessing  the  data  associated  with  the  corresponding  flight.  The  system  is  Implemented  as 


a  module  in  order  to  protect  the  inner  event  class  Identifiers.  The  structure  of  the  module  Is 
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simple,  snd  the  behavior  of  its  event  handlers  is  seif  explanatory.  The  system  is  of  course 
simplified  and  not  a  realistic  one,  but  it  shows  the  kernel  of  a  possible  more  realistic  system. 

EBL's  fairness  rules  (as  defined  in  chapter  2)  guarantee  that  each  request  is 
eventually  processed.  This  program  dons  not  attempt  to  control  the  order  in  which  requests 
are  processed.  For  example,  reservations  are  not  necessarily  handled  In  the  order  they  are 
issued.  In  order  to  get  a  more  fair  solution,  the  where  clause  of  the  second  event  handler 
can  be  changed  to: 

where  (f*fl  and  l>*n)  a  first  (reserve) 

In  this  case,  reservations  which  can  be  positively  answered  are  handled  on  a  FIFO  basis. 

6.4  Disk  Head  Scheduler 

The  problem  of  the  disk  head  scheduler  Is  presented  in  [Ho-74].  Basically,  the 
problem  is  to  reduce  the  average  waiting  time  of  a  process  wishing  to  access  the  disk  at 
some  cylinder.  The  first  suggestion  considered  there  Is  to  select  the  process  wishing  to 
move  the  disk  heads  the  shortest  distance.  This  solution  is  not  accepted  there,  since  a 
process  wishing  to  access  a  cylinder  at  one  edge  can  starve  forever. 

The  solution  shown  there  minimizes  the  frequency  of  changing  the  direction  of  the 
heads  movement,  like  the  behavior  of  an  elevator  algorithm.  The  solution  is  Implemented  by 
using  the  monitor  construct,  and  it  should  not  be  difficult  to  express  it  in  EBL.  However,  let 
us  return  to  the  original  (rejected)  solution  and  see  if  and  how  It  can  be  expressed  using 
each  of  the  following  mechanisms:  (1)  EBL  event  mechanism,  and  (2)  the  monitor  construct. 
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in  the  following  EBL  subprogram,  the  requests  are  represented  by  events  from 
the  class  request.  Each  process  wishing  to  access  the  disk  causes  a  request  event 
specifying  the  destination,  and  a  continuation  event  class  identifier.  The  continuation  event 
is  caused  by  the  scheduler  when  it  decides  to  select  the  process.  When  the  process 
decides  to  free  the  disk,  it  causes  an  event  from  the  class  release,  which  contains  the 
current  heads  position. 

request:  event  (Int,  event  (Int))  ;  {  parameters:  destination  and  continuation  } 

release:  event  (Int)  ;  {  the  parameter  is  the  current  heads  position  } 

on  release  (headpos:  Int)  a  request  (dest:  int,  c:  event  (Int)) 

where  mln  (abs  (headpos-dest)) 
par_cause  c  (dest)  {  allow  the  process  to  continue  } 

end  ; 

on  program_start 

par_cause  release  (0)  {  initial  heads  position  } 

end  ; 

As  can  be  seen,  the  whole  scheduling  algorithm  Is  implemented  by  one  trivial  event  handler 
and  an  additional  initialization.  In  order  to  implement  such  an  algorithm  using  the  monitor 
construct,  some  data  structure  must  be  added  for  keeping  the  destinations  of  the  waiting 
processes;  in  addition,  a  monitor  procedure  for  searching  the  data  structure  in  order  to 
select  the  next  request  must  be  explicitly  written,  and  the  solution  is  not  elegant.  The 
scheduled  waits,  which  are  used  in  [Ho-74]  in  his  solution  to  the  original  problem,  do  not 
contribute  anything  to  the  problem  we  consider  here. 

Let  us  analyze  the  reasons  for  the  difference  in  the  ease  of  expressing  the 
algorithm  in  the  two  cases.  The  first,  and  seemingly  obvious  reason  Is  the  existence  of  the 


predicate  mln  in  EBL.  However,  the  scheduled  waits  offer  a  similar  mechanism:  choosing  the 
waiting  process  having  the  maximal  priority  (minimum  value  of  a  parameter  associated  with 
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the  welting  process);  therefore,  this  reason  Is  not  so  clear. 

The  second  reason,  the  difference  between  EBL's  min  predicate  and  the 
scheduled  waits,  is  the  fundamental  one.  The  scheduled  waits  mechanism  allows 
associating  a  priority  with  the  waiting  process;  however,  this  priority  is  evaluated  when  the 
process  is  suspended  (when  executing  a  wait  statement)  and  cannot  be  modified 
dynamically.  Scheduled  waits  can  be  modeled  In  EBL  by  using  the  min  or  max  predicates; 
however,  in  EBL,  the  priority  of  a  waiting  process  (a  requestor  in  the  example)  is  evaluated 
dynamically  (in  the  where  clause)  and  is  more  powerful.  Now  it  should  be  clear  why  the 
scheduled  waits  cannot  be  used  to  solve  the  problem  considered  here. 

The  example  in  this  section  suffers  from  the  possibility  of  starvation.  Several 
comments  can  be  made  on  this.  First,  the  problem  can  be  eliminated  by  constructing  a 
slightly  more  complicated  scheduler  that  makes  use  of  an  additional  parameter  of  each 
request:  a  parameter  obtained  by  reading  the  latest  tick  value.  Clearly,  this  is  yet  another 
scheduling  algorithm,  but  there  is  no  other  choice  since  the  starvation  possibility  is  inherent 
in  the  algorithm  and  is  not  caused  by  choosing  one  mechanism  or  another.  Second,  our 
purpose  has  not  been  to  justify  the  algorithm  but  rather  to  use  it  as  some  concrete  example 
in  the  above  discussion. 

6.6  The  Five  Dining  Philosophers 

The  problem  of  the  five  dining  philosophers  was  presented  in  [Di-71],  It  involves 
five  philosophers  spending  their  time  in  Infinite  cycles  of  eating  and  thinking.  The 
philosophers  sit  at  a  round  table  and  there  is  one  fork  between  every  two  adjacent 
philosophers  (total  of  five  forks).  In  order  to  eat,  each  philosopher  needs  the  fork  to  Its  left 
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and  the  fork  to  its  right.  The  above  paper  shows  how  deadlock  can  arise  when  solving  the 

problem  by  using  semaphores.  A  possible  solution  in  terms  of  EBL  Is: 

F:  event  (int)  ;  {  forks  class  } 

P:  event  (int,  int)  ;  {  philosophers  class  } 

on  P  (If,  rf:  int)  a  F  (i:  int)  a  F  (J:  Int)  where  lf=i  and  rf«j 
seq_cause 

{  eat  >  ; 

F  (If)  ;  {  free  left  fork  } 

F  (rf)  ;  {  free  right  fork  ) 

{ think  }  ; 

P  (If,  rf)  {  iterate  } 

end  ; 

on  program_start 
par_cause 

{  create  (start)  the  five  philosophers  } 

P  (1,  2)  ;  P  (2,  3)  ;  P  (3,  4)  ;  P  (4,  5)  ;  P  (6,  1)  ; 

{  create  the  five  forks  } 

F  (1)  ;  F  (2)  ;  F  (3)  ;  F  (4)  ;  F  (6) 

end  ; 


The  above  solution  is  deadlock  free  since  it  basically  makes  use  of  multiple  P 
operations.  Actually,  a  class  of  philosophers,  all  executing  the  same  event  handler,  has 
been  created.  As  implied  by  the  problem,  the  order  in  which  the  philosophers  are  selected 
for  restarting  their  cycles  Is  not  defined;  however,  the  solution  can  be  easily  modified  to  be 
more  fair  by  changing  the  where  clause  of  the  first  event  handler  to: 
where  (lf«l  and  rf»j)  a  first  (P) 

In  this  case,  if  philosopher  P  is  selected  for  restarting  its  cycle,  P  is  the  longest  waiting 
philosopher  among  all  philosophers  which  are  currently  waiting  and  both  of  the  forks  they 
need  are  not  in  use. 
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6.6  Summary 

This  chapter  and  the  previous  one  have  explicitly  dealt  with  the  expressive 
power  of  EBL.  The  previous  chapter  has  shown  how  variables  can  be  implemented  in  terms 
of  single_use  events.  This  chapter  has  shown  another  way  to  Implement  shared  mutable 
objects;  this  time  in  terms  of  multi_use  events.  The  power  and  the  roles  of  some  of  EBL's 
predicates  have  been  demonstrated,  it  seems  that  synchronization  problems  and  problems 


involving  resource  allocation  are  especially  easy  to  solve  in  EBL. 
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7.  Virtual  System  Implementation 

The  purpose  of  this  chapter  is  to  investigate  implementation  schemes  which  are 
natural  to  the  language.  A  system  with  virtually  unlimited  computational  resources  will  'ie 
selected  as  a  concrete  example.  This  investigation  is  not  useless  since,  as  will  be  seen  in 
the  following  chapters,  its  results  can  be  easily  adapted  to  more  realistic  computer  systems. 
In  some  places  In  this  chapter  the  existence  of  unlimited  computational  resources  is  not 
exploited  since  the  purpose  is  to  develop  schemes  which  can  be  employed  in  reality  (after 
some  adaptation). 

7.1  Overview 

This  chapter  assumes  a  virtual  system  having  an  architecture  of  a  fully 
connected  processor  network  with  unlimited  computational  resources  (processors, 
processors'  local  storage,  and  link  capacity).  An  attractive  implementation  on  such  a 
system  associates  an  event  class  manager  ECM,  with  each  event  class  identifier  in  the 
program,  and  an  event  handler  manager  EHM,  with  each  event  handler.  Each  manager  is 
assigned  to  a  distinct  processor. 

An  ECM  is  responsible  for  events  from  the  corresponding  event  class.  It 
maintains  the  event  objects  In  an  event  list  which  may  be  (but  not  necessarily)  implemented 
as  a  linked  list.  Whenever  a  new  event  is  to  be  caused  by  some  instance  of  an  event 
handler  the  corresponding  ECM  receives  the  event  object  and  inserts  it  into  its  event  list. 
It  then  may  broadcast  a  message  to  all  the  relevant  EHM's  to  check  whether  they  can  now 
find  new  matching  event  collections. 
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An  EHM  is  a  cyclic  process  that  repeatedly  tries  to  find  new  matching  event 
collections.  It  does  it  by  scanning  the  relevant  event  lists,  by  exchanging  messages  with 
the  corresponding  ECM's.  When  it  finds  a  matching  event  collection  it  must  verify  that  the 
single_use  events  In  the  collection  have  not  been  used  so  far  (i.e.,  they  still  exist)  and  can 
be  used  by  it,  all  in  an  atomic  action  called  the  acquisition.  Then  it  can  activate  a  new 
instance  of  the  event  handler,  by  allocating  a  new  processor  for  this  task. 

An  activated  instance  of  an  event  handler  has  to  evaluate  parameters  and  to 
cause  events.  Since  there  is  a  lot  of  concurrency  to  be  exploited  even  within  a  single 
instance  of  an  event  handler,  new  processors  wilt  be  allocated  as  needed  to  achieve  a  high 
degree  of  parallelism.  When  an  event  object  is  built,  a  message  is  sent  to  the 
corresponding  ECM,  which  inserts  the  object  into  its  event  list.  The  managers  and  the 
instances  of  event  handlers  communicate  with  each  other  by  exchanging  messages.  The 
messages  are  either  requests  (e.g.,  "insert  an  event  object  into  a  list"),  or  replies  (e.g., 
"here  is  the  next  list  element"). 

One  of  the  tasks  of  an  EHM  is  the  acquisition  of  single_use  events  in  a  matching 
event  collection.  The  problem  is  akin  to  that  of  locking  of  objects  in  a  distributed  database, 
and  a  two  phase  acquisition  (locking)  algorithm  can  be  employed.  As  in  many  existing  locking 
algorithms  deadlocks  can  be  prevented  »i  our  case  by  defining  a  total  order  on  all  objects  to 
be  locked.  The  drawback  of  this  approach  is  that  objects  are  locked  sequentially.  A 
scheme  in  which  deadlocks  are  prevented  by  using  a  partial  order  on  all  object  classes 
(event  classes)  is  developed  in  this  chapter.  The  advantage  of  this  scheme  Is  that  objects 
can  be  locked  by  a  requestor  (an  EHM)  concurrently,  thus  the  acquisition  action  can  be 


completed  faster. 
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The  EHM  algorithm  is  described  in  this  chapter  in  terms  of  a  conceptual  tool:  the 
event  space.  One  event  space  is  associated  with  each  event  handler  in  the  program.  Each 
of  the  n  axes  of  an  event  space  ranges  over  all  existing  events  from  one  of  the  n  event 
classes  defined  by  the  event  descriptor  list  of  the  event  hand'er.  Event  collections  can  be 
represented  as  points  in  the  n  dimensional  event  space.  Each  event  space  changes 
dynamically  and  the  role  of  the  corresponding  EHM  is  to  continually  check  whether  points  in 
the  event  space  correspond  to  matching  event  collections. 

The  behavior  of  an  EHM  is  determined  by  two  orthogonal  properties  of  the 
corresponding  event  handler.  The  first  property  is  the  existence  of  single_use  event  class 
Identifiers  in  the  event  descriptor  list.  If  the  event  descriptor  list  contains  at  least  one 
event  class  identifier  of  a  single_use  type  the  event  handler  is  a  single_use  event  handler, 
otherwise  it  is  a  multi _use  event  handler.  The  second  property  is  the  existence  of 
predicates  in  the  where  clause  of  the  event  handler.  According  to  the  above  properties 
there  are  4  different  cases: 

Case  1 :  A  mutti_use  event  handler  without  predicates  in  its  where  clause. 

Case  2:  A  single_use  event  handler  without  predicates  in  its  where  clause. 

Case  3:  A  multi_use  event  handler  with  at  least  one  predicate  in  its  where  clause. 

Case  4:  A  single_use  event  handler  with  at  least  one  predicate  in  its  where  clause. 

In  all  above  cases,  an  EHM  begins  a  search  for  matching  event  collections  after 
receiving  a  message  from  an  ECM  (saying  that  a  change  in  its  event  list  has  occurred).  In 
cases  1-3,  the  EHM  only  checks  new  points  in  its  event  space  whereas  in  case  4,  in 
general,  the  whole  event  space  has  to  be  searched.  In  cases  1  and  3,  once  a  matching 
event  collection  is  found  an  instance  of  the  event  handler  is  activated  by  the  EHM.  In 
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cases  2  and  4,  however,  the  EHM  has  first  to  acquire  the  slngle_use  events  in  the  event 
collection  (by  the  acquisition  algorithm)  and  only  then  it  activates  an  instance  of  the  event 
handler. 

Before  an  EHM  begins  a  search  for  matching  event  collections  it  has  to  find  the 
current  boundaries  of  its  event  space.  These  boundaries  consist  of  the  current  boundaries 
of  all  the  relevant  event  lists.  The  action  of  finding  the  boundaries  cannot  be  implemented 
as  a  sequence  of  actions  reading  the  needed  values  since  a  set  of  values  inconsistent  with 
each  other  may  be  obtained  (examples  are  given  in  section  7.7).  The  boundaries  must  be 
sampled  at  exactly  the  same  point  in  time.  An  implementation  of  such  an  action  in  a 
distributed  system  without  any  centralized  control  Is  not  trivial.  Strategies  based  on  locks  or 
timestamps  can  be  employed. 

An  implementation  of  EBL  must  guarantee  the  language  fairness  rules.  The 
fundamental  idea  in  guaranteeing  the  fairness  rules  is  that  each  EHM  should  detect  a  case 
in  which  it  could  use  an  event  in  many  opportunities  but  it  failed  due  to  contention  with 
other  EHM's.  When  an  EHM  detects  that  it  failed  it  acts  to  reduce  the  likelihood  that  It  fails 
in  the  future.  It  increments  a  counter  (a  failure  counter )  associated  with  the  EHM  and  the 
ECM  whose  event  is  a  reason  for  the  failure.  Each  ECM  knows  the  values  of  the  relevant 
failure  counters.  Therefore,  it  can  give  a  higher  priority  to  requests  associated  with  the 
EHM  whose  counter  has  the  highest  value. 

In  the  general  case,  an  event  list  can  be  Implemented  as  a  doubly  linked  list.  In 
certain  cases,  however,  optimizations  can  be  made.  In  some  cases  an  event  list  can  be 
replaced  by  a  counter  and  In  others  by  a  record  variable.  Sorting  an  event  list  can  result  in 
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a  better  performance  in  certain  cases.  These  optimizations  and  others  are  discussed  in  a 
section  7.12. 

The  rest  of  this  chapter  further  develops  the  ideas  discussed  in  this  section. 

7.2  The  Virtual  System 

The  virtual  system  consists  of  a  very  large  number  of  processors;  each 
processor  is  directly  connected  to  all  the  other  processors,  and  is  equipped  with  unlimited 
local  storage.  The  processors  are  organized  by  some  mechanism  in  a  free  processor  pool. 
Whenever  a  processor  is  needed  for  some  computational  task,  it  can  be  immediately 
obtained  from  the  pool.  When  the  task  is  complete,  the  processor  is  returned  to  the  free 
processor  pool. 

The  links  connecting  processors  are  of  a  very  high  speed  (unlimited  capacity),  a 
very  low  propagation  delay,  and  no  overhead  is  associated  with  sending  (receiving) 
messages  through  them.  Thus,  the  cost  of  communication  between  program  objects  residing 
on  different  processors  is  zero.  This  property  of  the  system  encourages  the  allocation  of  a 
distinct  processor  for  each  task  in  order  to  achieve  good  time  performance. 

It  is  important  to  observe  that  the  above  view  of  the  sy:  tern  does  not  restrict 
the  applicability  of  the  analysis  in  this  chapter  to  a  network  of  processors  communicating 
through  communication  links;  the  results  apply  also  to  a  multiprocessor  system  containing  a 
shared  memory.  The  main  difference  is  that  in  the  latter  case,  program  object  A  residing  on 
one  processor  can  access  the  local  data  of  program  object  B  residing  on  another  processor 
without  bothering  B  (as  long  as  undesired  interferences  do  not  occur)  and  thus  better 
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performance  cun  be  achieved,  unless  the  shared  memory  becomes  a  bottleneck. 

In  this  system,  once  an  object  (such  as  a  manager,  an  Instance  of  an  event 
handler,  or  an  event  object)  is  assigned  to  a  processor  there  is  no  need  to  move  it  to 
another  processor  (although  it  may  be  copied  to  other  processors).  Thus,  objects  can  be 
addressed  by  processor  number  plus  some  additional  unique  identifier.  In  the  sequel  P(Oj) 
denotes  the  processor  on  which  object  0|  currently  resides.  The  EHM  associated  with 
event  handler  H  is  denoted  by  M(H);  similarly,  the  ECM  associated  with  event  class 
identifier  E  is  denoted  by  M(E). 

7.3  The  Event  Handler  Manager 

The  role  of  an  EHM  is  to  repeatedly  try  to  find  new  event  collections  which  match 
the  event  handler  heading.  For  each  such  collection  to  acquire  the  single_use  events  in  the 
collection  (perform  the  acquisition  action  defined  earlier),  and  then  to  activate  a  new 
instance  of  the  event  handler.  Before  one  designs  an  EHM  algorithm  answers  should  be 
given  to  the  following  questions: 

1.  At  which  points  during  the  course  of  the  computation  should  an  EHM  start 
searching  for  new  event  collections? 

2.  How  and  whether  an  EHM  should  keep  information  saying  for  which  event 
collections  the  event  handler  has  already  been  activated? 

3.  Is  it  sufficient  for  an  EHM  to  check  whether  an  event  collection  is  matching  once, 
or  can  It  happen  that  at  one  point  In  time  an  event  collection  does  not  match,  and 
later  it  matches  an  event  handler  heading? 

4.  How  does  an  EHM  acquire  the  slngle_use  events  In  a  matching  event  collection? 
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Can  deadlocks  occur? 

The  first  question  Is  discussed  below.  In  a  system  like  our  virtual  system,  in 
which  processing  power  is  unbounded,  or  if  time  performance  is  of  no  Importance,  an  EHM 
can  be  implemented  as  a  process  which  continually  checks  whether  there  are  new  matching 
event  collections.  However,  since  the  purpose  of  this  chapter  is  to  introduce  schemes  that 
can  be  easily  adapted  to  real  world  systems,  we  shall  not  accept  such  a  scheme. 

The  above  scheme  Is  time  consuming,  and  it  ignores  the  special  semantic 
properties  of  the  language  which  allow  fulfilling  the  EHM  role  much  more  efficiently.  There  is 
no  need  to  search  for  event  collections  unless  there  is  a  change  in  at  least  one  of  the 
event  lists  associated  with  event  class  identifiers  appearing  in  the  event  handler  heading. 
Not  every  change  should  be  considered.  For  an  event  class  identifier  appearing  in  the 
event  descriptor  list,  only  insertions  of  new  event  objects  are  relevant.  For  an  event  class 
Identifier  appearing  as  an  argument  of  an  exist  (none)  predicate,  the  search  should  start 
only  if  the  list  changes  from  an  empty  (not  empty)  list  to  a  not  empty  (empty)  list.  Since  the 
managers  of  a  given  program  are  fixed  and  known  at  compile  time,  an  ECM  can  signal  a 
known  fixed  group  of  EHM's  whenever  a  relevant  change  occurs  in  its  event  list.  This  signal 
Is  broadcast  by  the  ECM  to  the  relevant  EHM's.  If  the  event  class  identifier  appears  in  the 
headings  of  n  event  handlers  then  at  most  n  ECM's  should  be  notified  when  the  event  list 
changes. 


The  answer  to  the  second  question  depends  on  the  types  of  the  event  class 
identifiers  in  the  event  descriptor  list.  If  there  Is  at  least  one  event  class  identifier  of  a 
single_use  type,  i.e.,  the  event  handler  is  a  slngle_use  event  handler,  there  Is  no  need  to 
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keep  Information  saying  for  which  event  collections  the  event  handler  has  already  been 
activated;  the  reason  is  that  the  single_use  events  in  such  event  collections  are  forgotten. 
If  all  event  class  identifiers  are  of  multi-use  types,  l.e.,  the  event  handler  Is  a  multi _use 
event  handler,  the  information  Is  needed.  A  way  for  keeping  the  information  is  described  in 
section  7.6. 

The  answer  to  the  third  question  depends  on  the  existence  of  predicates  in  the 
where  clause.  If  there  are  predicates,  an  event  collection  that  does  not  match  the  event 
handler  heading  at  one  point  In  time  may  match  at  another  point  in  time.  If  there  are  no 
predicates,  this  cannot  happen.  A  way  for  keeping  information  about  event  collections 
which  should  be  revisited  is  described  in  section  7.6. 

7.4  The  Acquisition  Algorithm 

The  fourth  problem  of  the  previous  section,  acquisition  of  the  single_use  events 
of  a  matching  event  collection,  poses  a  difficulty.  On  one  hand,  the  acquisition  should  be  an 
atomic  action;  on  the  other  hand,  several  EHM's  may  wish  to  acquire  the  same  object.  The 
problem  arises  since  EHM's  operate  concurrently  in  a  distributed  system  without  any 
centralized  control.  The  problem  Is  akin  to  that  of  locking  objects  needed  by  a  transaction 
In  a  distributed  database  system,  but  It  Is  simpler  due  to  several  reasons.  First,  in  our  case 
locked  objects  (single_use  events)  are  never  unlocked.  Second,  if  an  EHM  finds  that  an 
object  it  wishes  to  lock  is  already  locked  it  aborts  the  attempt  to  lock  the  object  and  It 
never  needs  to  lock  this  object  again.  Third,  In  our  case  the  requestors  (EHM's)  are  fixed, 
and  each  of  which  tries  to  lock  objects  from  a  fixed  group  of  object  classes. 
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The  problem  can  be  solved  by  a  two  phase  acquisition  algorithm  which  Is 
reminiscent  of  the  two  phase  commit  protocol  of  [Gr-78].  In  the  first  phase,  the  booking 
phase,  the  EHM  requests  the  relevant  ECM's  to  mark  the  single_use  events  as  booked.  If 
the  first  phase  succeeds,  i.e.,  all  needed  objects  are  successfully  booked,  the  second 
phase  In  which  the  EHM  requests  the  ECM's  to  mark  the  events  It  has  previously  booked  as 
acquired  is  entered. 

If  in  the  booking  phase  an  EHM  is  notified  that  an  object  It  tries  to  book  is 
already  acquired,  the  EHM  frees  all  objects  It  has  successfully  booked  and  aborts  the 
algorithm.  If  a  booked  object  Is  found,  the  acquisition  algorithm  Is  suspended  until  the 
object  is  either  freed  or  acquired.  In  order  to  successfully  acquire  n  objects  an  EHM  has  to 
send  at  most  2n  messages,  assuming  each  ECM  keeps  suspended  requests.  The  above 
algorithm  is  susceptible  to  deadlock.  A  deadlock  can  involve  only  EHM's  executing  the  first 
phase  of  the  acquisition  algorithm  since  in  the  second  phase,  the  needed  objects  are 
already  booked  and  therefore  out  of  the  contention. 

In  general,  deadlocks  among  requestors  of  resources  can  be  treated  in  one  of 
the  following  ways  [Ch-74b]: 

1.  Detect  deadlocks  after  they  occur,  then  cure  the  problem,  e.g.,  by  pre-empting 
resources  in  a  way  which  breaks  the  deadlock. 

2.  Avoid  deadlocks  by  forcing  each  requestor  to  request  all  the  resources  It  needs 
In  advance.  Only  requests  which  do  not  lead  to  deadlock  are  granted. 

3.  Prevent  deadlocks.  In  this  case,  deadlocks  cannot  occur  due  to  the  underlying 
system  algorithm. 
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In  our  case,  deadlocks  can  be  prevented  in  most  cases  if  all  EHM's  adhere  to  the 
following  booking  rule: 

B1.  Objects  are  booked  sequentially  one  at  a  time  in  an  order  preserving  a  global 
order  (chosen  by  the  compiler)  on  all  event  class  identifier  'n  the  program. 

The  only  case  not  covered  by  the  above  rule  Is  that  of  more  than  one  event  handler  each 
containing  the  same  event  class  identifier  of  a  slngie_use  type  in  more  than  one  event 
descriptor  In  Its  event  descriptor  list.  One  way  to  prevent  deadlocks  in  this  uncommon  case 
is  by  adding  the  following  rules  to  the  corresponding  EHM's: 

B2.  Every  distinct  single_use  event  in  the  event  collection  is  booked  at  most  once. 
This  takes  care  of  an  event  collection  containing*the  same  event  more  than  once. 

B3.  Events  from  an  event  class  are  booked  according  to  some  fixed  order  on  the 
event  objects  in  the  event  list.  An  example  of  such  an  order  is  the  order  of 
insertion  of  the  event  objects  into  the  event  list  (which  is  not  necessarily 
Identical  to  the  order  of  the  events  in  the  event  list) 

Another  way  is  to  replace  rule  B3  by: 

B3'.  All  events  from  the  same  event  class  are  booked  by  the  EHM  in  one  request, 
executed  as  an  atomic  action  by  the  ECM. 

Since  such  a  multiple  book  request  is  processed  by  one  processor  (on  which  the  ECM 
resides),  its  implementation  poses  no  problems. 

Similar  algorithms  for  locking  objects,  which  do  not  prevent  deadlocks  (in  the 
sense  defined  earlier),  normally  use  some  aging  mechanism  (e.g.,  timestamps)  in  order  to 
prevent  a  requestor  from  waiting  forever  due  to  retries  (e.g.,  after  pre-emptions)  [Ch-74b, 
Ba-76,  St-78bl.  No  such  mechanism  Is  needed  in  our  case  since  there  are  no  retries.  The 
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problem  of  requestors  waiting  forever  does  not  occur  if,  for  example,  each  ECM  fulfills  book 
requests  in  a  FIFO  order  (except  when  requests  are  suspended). 

One  should  observe  that  the  booking  algorithm  prevents  deadlocks  by  defining  a 
total  order  on  classes  of  resources  and  not  on  the  resources  themselves.  The  number  of 
those  classes  is  fixed  and  known  to  the  compiler,  whereas  the  number  of  the  resources  In 
each  class  is  in  general  unbounded.  EHM's  executing  the  second  pnase  of  the  acquisition 
algorithm  cannot  be  involved  in  deadlocks  thus  they  can  acquire  all  needed  objects 
concurrently.  The  combined  acquisition  algorithm  Is  therefore  deadlock  free. 

A  drawback  of  the  previous  acquisition  algorithm  is  that  objects  are  booked 
sequentially.  This  restriction  (defined  in  rule  B1  earlier)  is  sufficient  for  preventing 
deadlocks  (except  for  the  cases  covered  by  rules  B2,  and  B3  or  B31)  but  can  be  relaxed  as 
shown  In  the  rest  of  this  section.  The  semantics  of  the  language  can  be  exploited  to  allow 
concurrency  in  the  booking  phase.  In  a  general  problem  of  requestors  locking  objects,  the 
objects  are  dynamically  selected  and  may  be  data  dependent.  In  our  case  however,  the 
classes  of  objects  required  by  each  requestor  (EHM)  are  known  in  advance  (at  compile 
time).  Our  scheme  can  be  applied  to  any  case  where  a  fixed  number  of  requestors  book 
objects  from  a  fixed  number  of  object  classes;  the  object  classes  are  disjoint  and  each  can 
change  In  time.  Each  requestor  books  objects  from  a  fixed  set  of  object  classes;  one  or 
more  disjoint  objects  from  each  class.  The  scheme  will  be  described  in  these  general  terms 
(the  corresponding  terms  in  our  case  appear  In  parentheses). 


Let  G  *  (Nr,  Nq;  A)  be  a  bipartite  undirected  graph  defined  as  follows:  Every 
requestor  (EHM)  Is  represented  by  exactly  one  node  R|  in  Nr,  and  every  object  class  (event 
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class  Identifier  of  a  slngle_use  type)  is  represented  by  exactly  one  node  Oj  in  Nq.  The  set 
of  arcs  A  contains  exactly  one  arc  connecting  R{  and  Oj  if  R(  locks  objects  from  object  class 
Oj.  An  example  of  such  a  graph  Is  given  in  Figure  7.1.  Since  G  is  a  bipartite  graph  every 


cycle  C  in  G  contains  an  even  number  of  nodes  2m  and  has  the  form  (R  ,  0_  ,  R_  ,  0_  ,  ... 

po  **o  P1  "1 

*  rd  On  „)•  Every  cycle  in  G  is  a  potential  for  a  deadlock.  However,  since  each  Oi 
Hn-i  Hm- 1  j 

represents  a  class  of  objects,  a  deadlock  may  happen  only  If  for  every  path  (Rp^,  O^,  Rp^) 
In  the  cycle,  where  j=(i*1)  mod  m,  Rp^  and  Rp^  try  to  lock  the  same  object  from  class  O^.  In 
such  case  a  deadlock  exists,  for  example,  when  Rp^  has  successfully  locked  the  object 
from  class  0q(  for  1*0,  ...  ,  m-1.  (This  Is  reminiscent  of  the  possibility  of  deadlock  In  the  five 
dining  philosophers  problem  [Di-71].) 


Figure  7.1  The  requests  graph  G 


In  general,  G  is  a  disconnected  graph  consisting  of  several  connected 
components.  G  can  be  separated  to  its  n  biconnected  components  (in  the  articulation  points 
of  each  of  Its  connected  components);  appropriate  (polynomial  time)  algorithms  can  be 

found,  e.g.,  in  [Re-77b].  Let  ,  S2 . Sn  be  the  sets  of  object  classes  corresponding  to 

the  n  biconnected  components.  For  every  I,  J  l/J  the  set  S(nSj  is  either  empty  or  contains 
exactly  one  element.  The  articulation  points  for  G  of  Figure  7.1  are  nodes  R2,  Rg,  06,  and 
Oz;  and  the  sets  of  object  classes  are  S.,*{00,  06),  S2*{01,  04,  06),  Sg*{02,  Og,  07>, 
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08>,  and  S6«{07,  Og>. 

Let  G'  =  (N's,  N'0;  A1)  be  the  reduced  bipartite  undirected  graph  of  G  defined  as 
follows:  Every  set  S(  is  represented  by  exactly  one  node  in  N'g.  if  SjOSj  *  {O^}  then  Ok  is 
represented  by  exactly  one  node  in  N'q;  this  node  is  connected  by  exactly  one  arc  to  S(, 
and  by  exactly  one  arc  to  Sj.  From  the  construction  of  G1  it  is  clear  that  it  is  acyclic.  The 
reduced  graph  for  G  of  Figure  7.1  is  depicted  In  Figure  7.2. 


Figure  7.2  The  reduced  graph  G’ 

In  order  to  prevent  deadlocks  it  is  sufficient  to  define  a  total  order  on  the 
elements  (object  classes)  of  each  S|  and  not  on  all  object  classes  (all  event  class 
Identifiers  of  the  program).  The  union  of  these  total  orders  defines  a  partial  order  P  on  the 
set  of  all  object  classes;  the  fact  that  the  graph  corresponding  to  P  contains  no  cycles 
stems  from  the  fact  that  G'  is  acyclic.  A  possible  partial  order  for  the  reduced  graph  of 
Figure  7.2  Is  shown  In  Figure  7.3. 


Figure  7.3  A  partlel  order  P  on  object  classes 
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Rule  B1  can  be  replaced  by  the  following  relaxed  rule: 

B1'.  Objects  are  locked  (booked)  by  a  requestor  (EHM)  in  any  partial  order  P' 
consistent  with  P;  i.e.,  object  class  0|  precedes  object  class  Oj  In  P  implies 
locking  an  object  of  class  Oj  precedes  locking  an  o’ject  of  class  Oj  in  P'. 
Unordered  locking  operations  can  be  executed  concurrently. 

In  the  relaxed  locking  (booking)  rule,  objects  from  distinct  classes  belonging  to  different 
sets  Sj,  Sj  can  be  locked  concurrently.  In  our  example,  requestor  R2  can  lock  objects  from 
class  0Q  then  lock  objects  from  jlass  06,  and  concurrently  with  these  operations  lock 
sequentially  objects  from  classes  0^,  O4,  and  Og.  In  the  relaxed  scheme,  the  number  of 
messages  an  EHM  has  to  send  in  order  to  successfully  acquire  n  objects  Is  still  at  most  2n 
but  the  acquisition  action  can  be  completed  faster  due  :o  concurrency  in  the  algorithm. 

Rule  B1 1  specifies  a  sufficiei.t  condition  for  preventing  deadlocks  (together  with 
rules  B2,  and  B3  or  B3*  appropriately  restated  in  the  more  general  terms)  but  it  is  not  a 
necessary  condition.  The  reason  is  that  nodes  in  Nq  represent  classes  of  objects  and  not 
objects.  For  example,  in  our  case,  if  both  Hj  and  H2  use  events  from  two  classes  Ej,  E2 
but  H-j  specifies  even  parameters  (in  its  where  clause)  whereas  H2  specifies  odd 
parameters,  ordering  of  E^  and  E2  is  not  required  whereas  the  above  scheme  orders  them. 
Extending  our  scheme  to  cover  such  cases  requires  decision  whether  two  boolean 
expressions  (in  where  clauses)  are  mutually  satlsflable.  Unfortunately,  the  problem  whether 
two  general  boolean  expressions,  whose  terms  contain  relations  between  integer 
expressions  (containing  the  operators  +,  -,  *,  ar  d  /),  are  mutually  satlsflable  is  undecidable. 


Section  7.6 


-  132  - 


The  Event  Space 


7.5  The  Event  Space 

Before  the  various  cases  of  the  EHM  algorithm  are  described,  several  terms  will 
be  introduced.  Let  n  be  the  number  of  event  class  identifiers  in  the  event  descriptor  list  of 
an  event  handler.  Each  collection  of  events  appropriately  associated  with  the  event  class 
identifiers  can  be  represented  as  a  point  in  an  n  dimensional  space,  the  event  space,  whose 
axes  represent  the  n  event  class  identifiers.  Each  axis  ranges  over  all  existing  events  from 
the  corresponding  event  class  (and  not  over  all  possible  events  from  the  class).  One  event 
space  is  associated  with  each  event  handler. 

Event  spaces  change  dynamically:  An  event  space  associated  with  a  mutti__use 
event  handler  cannot  shrink  In  time.  An  event  space  associated  with  a  slngle_use  event 
handler  H  can  grow  and  shrink  in  time  since  a  part  of  t'.K  event  space  is  deleted  each  time 
a  single_use  event  of  one  of  the  event  classes  in  the  event  descriptor  list  is  used  by  some 
event  handler  (not  necessarily  by  H).  In  the  sequel,  the  part  of  an  event  space  obtained  by 
selecting  along  each  axis  only  points  between  the  origin  and  some  fixed  point  is  called  a 
rectangular  event  subspace.  The  term  event  subsf  ice  Increment  is  used  when  referring  to 
the  part  of  an  event  space  obtained  as  tho  (set)  difference  of  two  rectangular  event 
subspaces,  one  containing  the  other.  The  term  event  subspace  is  used  in  the  general  sense 
of  a  part  of  an  event  space.  The  EHM  algorithms  can  be  described  and  can  be  easily 
visualized  in  terms  of  event  subspaces.  As  an  example  consider  the  following  event  handler 
heading: 

on  E^  (...)  a  E2  (...)  where  ... 

Figure  7.4  depicts  the  corresponding  event  space  at  a  point  in  time  at  which  7  events  from 
class  E.)  exist  and  6  events  from  class  E2  exist.  The  events  are  marked  by  x's  on  the  axes 
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in  Figure  7.4;  each  of  the  42  dots  represents  an  event  collection.  The  dashed  line  1-1* 
(2-2‘)  and  the  two  axes  define  a  rectangular  event  subspace  containing  6  (25)  event 
collections.  The  dashed  lines  1-1*,  2-2'  and  the  two  axes  define  an  event  subspace 
increment  containing  1 9  event  collections. 

2 

1 

Figure  7.4  An  event  space 

7.6  Finding  Matching  Event  Collections 

This  section  deals  with  the  part  of  the  EHM  algorithm  for  finding  new  matching 
event  collections.  There  are  four  cases  according  to  the  answers  given  to  questions  2  and 
3  of  section  7.3. 

7.6.1  Case  1:  Multi  use  Event  Handler  without  Predicates 

This  case  deals  with  a  multi_use  event  handler  without  predicates  in  its  where 
clause.  Since  there  are  no  predicates  there  is  no  need  for  visiting  a  point  in  the  event 
space  more  than  once.  Therefore,  some  way  for  covering  the  nonshrinking  n  dimensional 
event  space  is  needed.  Some  diagonal  order  could  be  used  but  at  each  step  n  messages 
should  be  sent,  one  for  each  of  the  n  ECM's,  for  finding  the  next  event  collection  to  be 
checked.  An  algorithm  which  always  covers  an  event  subspace  increment  by  proceeding 
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row  by  row,  within  each  row  column  by  column  etc.  in  the  matrix  corresponding  to  the  event 
space,  is  simpler  and  more  efficient.  At  each  step  a  message  for  only  one  ECM  is  needed 
except  on  the  event  subspace  boundaries  (e.g.,  when  a  new  row  is  started). 

The  event  space  is  only  a  conceptual  tool.  There  is  no  need  to  actually  build  a 
matrix  which  corresponds  to  the  event  space  (whose  elements  are  event  collections)  and 
thus  keeping  the  information  about  the  event  space  points  in  memory.  The  needed 
Information  is  easily  obtained  from  the  relevant  event  lists  by  keeping  two  references  to  the 
current  boundaries  within  each  event  list  and  a  reference  to  the  currently  checked  event 
from  that  list. 

Each  time  the  EHM  starts  the  search  for  matching  event  collections  the 
previously  searched  Rectangular  event  subspace  is  expanded  along  one  dimension  to  the 
current  boundary  of  the  event  space  in  that  dimension.  All  the  points  added  to  the 
rectangular  event  subspace  by  this  expansion  (adding  an  event  subspace  increment)  are 
checked  and  instances  of  the  event  handler  are  activated  as  necessary.  This  procedure  is 
repeated  for  all  n  dimensions.  At  the  end,  a  flag  called  the  restart  flag  is  tested  to  see 
whether  messages  (from  the  relevant  ECM's)  indicating  that  new  events  occurred,  have 
been  received  while  the  EHM  was  performing  the  search.  If  the  restart  flag  is  set  the  EHM 
restarts  the  search,  otherwise  the  search  is  suspended  untii  such  messages  arrive. 

Let  us  examine  the  number  of  messages  M,  an  EHM  has  to  send  in  order  to  cover 
an  event  subspace  increment.  The  number  of  messages  required  on  event  subspace 
boundaries  becomes  less  significant  as  the  number  of  events  in  the  n  event  lists  increases; 
thus,  these  messages  are  ignored  In  the  sequel.  Let  Nj  be  the  number  of  existing  events  in 
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event  list  i  when  the  previous  search  began,  and  dj  be  the  number  of  events  added  until  the 
current  search  started.  The  number  of  EHM  messages  needed  for  covering  the  event 
subspace  increment  is  M  =  II  (Nj+dj)  -  II  Nj;  i.e.,  the  number  of  event  collections  in  the 

i  ; 

event  subspace  increment.  If  only  one  event  list  (k)  has  changed  then 

M  =  dk  max  ( II  Nj,  l).  The  max  takes  care  of  the  case  in  which  n=1. 
i/k 

M  can  also  be  written  as  M  =  I"I  N;  ( I"I  (1  ♦ — -)-l).  If  for  all  i  — -  «  .,  as  is  the 

I  '  I  Nj  Nj 

case  when  the  event  lists  grow  (Nj  increases)  and  the  EHM  responds  fast  enough  to 

changes  in  the  event  lists  (dj  is  small)  then  M  can  be  approximated  by  M  =  11  Nj  Y.  — If  for 

I  I  Ni 

all  i  Nj=N  then  M  =  Nn_1  Y.  dj;  if  in  addition,  for  ail  i  df=d  then  M  =  Nn‘  ^d. 

I 

The  efficiency  of  an  EHM  can  be  improved  by  allocating  more  than  one  processor 
for  the  event  subspace  search.  A  possible  way  is  that  the  EHM  allocates  several  slave 
processors  for  this  task  and  assigns  a  disjoint  part  of  the  event  subspace  increment  to 
each  of  them.  For  example,  in  case  of  a  two  dimensional  event  space  each  slave  processor 
can  be  assigned  a  row  in  the  corresponding  matrix.  Coordination  among  the  slaves  is 
required  especially  when  predicates  exist  in  the  where  clause  of  the  relevant  event 
handler. 

7.6.2  Case  2:  Single_use  Event  Handler  without  Predicates 

This  case  deals  with  a  single_use  event  handier  without  predicates  in  its  where 
clause.  The  rectangular  event  subspace  and  the  scheme  for  covering  it  can  also  be  used  in 
this  case.  Whenever  an  event  collection  is  selected  for  activating  an  instance  of  an  event 
handler  its  single_use  events  are  forgotten;  therefore,  the  event  space  does  not  contain 
any  point  associated  with  a  selected  (used)  event  collection.  The  covered  part  of  the 
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rectangular  event  subspace  represents  event  collections  which  did  not  match  (and 
therefore  will  never  match)  the  event  handler  heading. 

When  a  matching  event  collection  is  found  its  single_use  events  are  acquired  by 
the  two  phase  acquisition  algorithm  described  earlier  in  this  chapter.  An  instance  of  the 
event  handler  is  activated  if  the  acquisition  succeeds.  When  an  event  is  acquired  it 
cannot  simply  be  deleted  from  the  event  list  since  references  to  it  can  exist  in  various 
.nanagers.  A  scheme  for  handling  this  difficulty  is  suggested  in  section  7.9. 

Let  N'j  be  the  number  of  existing  events  in  event  list  i  when  the  previous  search 
began.  During  the  previous  search  some  of  these  N'j  could  be  used  (by  this  EHM  or  by 
others).  Let  N"j  (N"j<N'j)  be  the  number  of  existing  events  remaining  from  the  N'j  events 
when  the  previous  search  ended.  Between  the  end  of  the  previous  search  and  the 
beginning  of  the  current  search  some  of  the  N"j  events  could  be  used  (by  other  EHM's).  Let 
Nj  (Nj<N"|)  be  the  number  of  existing  events  remaining  from  the  N'j  events  when  the  current 
search  begins.  For  a  multi_use  event  class  Identifier  N'j=N"j=Nj;  this  is  the  reason  why  the 
distinction  between  these  3  values  is  not  needed  in  case  1 .  Let  dj  be  the  number  of  events 
added  to  event  list  i  after  the  beginning  of  the  previous  search  which  are  existing  at  the 
beginning  of  the  current  search. 

In  this  case,  the  number  of  EHM  messages  M  needed  for  covering  the  event 

subspace  increment  containing  the  event  collections  added  between  two  consecutive 

searches  is  at  most  FI  (Nj+d|)  -  II  N|.  The  reason  for  the  inequality  is  that  whenever  a 
I  I 

single_use  event  participating  in  an  event  collection  in  the  event  subspace  increment  is 


used,  a  part  of  the  event  space  Is  deleted  and  it  may  not  be  needed  to  check  some  of  its 
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event  collections. 

In  order  to  find  out  how  many  event  collections  D  are  deleted  from  the  event 
subspace  increment  when  a  single_use  event  e^  from  event  list  k  is  used  the  following 
algorithm  can  be  applied. 

1.  If  ek  is  in  the  group  of  dJl  added  events  then  0  =  max  ( 11  (Nj+dj),  l): 

itk 

set  d^sd^-1  for  later  applicaxons  of  this  algorithm. 

2.  if  ek  is  in  the  group  of  Nk  events  remaining  from  the  previous  search  then 

D  =  IT  (Nj+dj)  -  TT  N  j;  set  Nj(=NjC-1  for  later  applications  of  this  algorithm. 

I#k  U«k 

The  decrease  in  M  resulting  from  the  above  even  collections  deletion  depends  on  how  many 
of  these  event  collections  have  already  been  checked;  the  decrease  can  vary  from  0  to  D. 
The  decrease  can  be  D  only  If  ek  is  used  by  another  EHM.  If  ek  is  used  by  this  EHM  then  the 
decrease  can  be  at  most  D-1. 

7.6.3  The  Effects  of  Predicates 

One  of  the  effects  of  predicates  is  that  an  event  collection  that  does  not  match 
the  event  handler  heading  at  one  point  in  time  may  match  it  at  a  later  point  in  time.  This  may 
lead  to  an  inefficient  algorithm  which  repeatedly  checks  the  same  event  collections. 
However,  a  deeper  examination  of  the  nature  of  EBL's  predicates  reveals  that  this  can  be 
avoided  in  many  cases.  This  section  analyzes  the  effects  of  the  predicates  exist  and 
none;  the  results  hold  both  for  a  multl_use  event  handler  with  predicates  and  for  a 
slngle_use  event  handler  with  predicates.  The  effects  of  the  other  predicates  are 
analyzed  in  the  following  two  subsections. 
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Two  trivial  cases  can  be  easily  eliminated  by  the  compiler.  In  the  first  case,  the 
argument  of  an  exist  predicate  also  appears  in  the  event  descriptor  list;  in  such  case,  the 
predicate  can  be  eliminated  from  the  where  clause  without  changing  the  program  behavior. 
In  the  second  case,  the  argument  of  a  none  predicate  also  appears  in  the  event  descriptor 
list;  in  such  case,  the  whole  event  handier  can  be  deleted  without  changing  the  program 
behavior  since  no  event  collection  will  ever  match  its  heading. 

Thus,  we  can  assume  that  the  argument  of  an  exist  (none)  predicate  is  an  event 
class  identifier  which  does  not  appear  in  the  event  descriptor  list.  This  implies  that  the 
values  of  these  predicates  do  not  depend  on  the  checked  event  collections  and  therefore 
they  can  be  evaluated  before  searching  of  the  event  subspace  increment  is  started.  It  is 
true  that  while  the  event  subspace  is  being  searched  the  values  of  these  predicates  may 
change  but  since  the  checking  itself  has  no  side  effects  on  the  values  of  the  predicates 
(even  when  the  argument  is  of  a  single_use  type)  the  algorithm  can  proceed  as  if  the 
search  of  the  whole  event  subspace  Is  done  instantaneously  (in  zero  time).  Before  the 
search  of  the  current  event  subspace  increment  is  started  the  exist  (none)  predicates  are 
evaluated  and  only  if  they  are  all  satisfied  the  search  begins. 

There  are  cases  in  which  additional  information  can  be  obtained  from  evaluation 
of  the  predicates: 

1 .  If  the  argument  of  an  exist  predicate  is  of  a  multi_use  type  and  the  predicate  is 
satisfied  once,  It  can  be  eliminated  from  the  where  clause  since  from  now  on  it 
will  always  be  satisfied. 

2.  If  the  argument  of  a  none  predicate  is  of  a  multi_use  type  and  the  predicate  is 
not  satisfied  once,  the  EHM  with  all  the  associated  Information  can  be  deleted 
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and  the  computational  resources  it  holds  can  be  released,  since  the  event 
handler  will  never  be  activated  afterwards. 

7.6.4  Case  3:  Multi  use  Event  Handler  with  Predicates 

This  case  deals  with  a  multi_use  event  handler  with  at  least  one  predicate  in  its 
where  clause.  The  most  important  observation  in  this  section  is  tha*  once  a  rectangular 
event  subspace  has  been  searched  and  the  matching  event  collections  have  been  found, 
there  is  no  need  to  search  this  event  subspace  again.  Ihis  might  seem  somewhat 
unreasonable  but  the  following  analysis  of  the  nature  of  EBL's  predicates  shows  that  the 
observation  is  true.  The  previous  section  suggested  a  scheme  for  handling  the  predicates 
exist  and  none;  this  scheme  does  not  involve  revisiting  points  in  the  event  space. 

The  next  important  observation  is  that  the  remaining  predicates  all  have  the 
flavor  of  minimizing  (maximizing)  some  value.  The  min  (max)  predicate  does  it  for  an  integer 
expression,  and  the  first  (last)  predicate  does  it  for  the  index  of  the  event  in  the  event  list 
(assuming  that  an  event  list  Is  ordered  according  to  the  arrival  order  of  its  objects). 

If  at  one  iteration  (search)  of  the  EHM  all  matching  event  collections  of  the 
rectangular  event  subspace  checked  at  that  time  are  found,  then  at  later  iterations  no  new 
matching  points  in  this  event  subspace  can  be  found.  This  follows  from  the  optimizing  nature 
of  the  predicates,  from  the  fact  that  event  collections  selected  in  previous  iterations  are 
still  there  (since  all  events  are  of  multl_use  types),  and  from  the  fact  that  the  event 
objects  are  immutable.  This  is  the  reason  why  in  this  case  tnere  is  no  need  to  check  an 
event  collection  more  than  once. 
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Thus,  each  time  the  EMM  starts  a  search  the  points  In  previously  searched 
rectangular  event  subspaces  need  not  be  revisited.  Moreover,  depending  on  the  predicates, 
not  all  new  points  in  the  event  subspace  increment  need  be  checked.  For  example,  if  the 
where  clause  is  where  first(E)  and  a  matching  event  collection  has  already  been  found 
(containing  event  e  from  class  E)  in  an  earlier  searcn,  there  is  no  need  to  consider  new 
events  from  class  E  since  they  must  have  been  preceded  by  e.  Similarly  if  the  where 
clause  is  where  last(E)  and  d  events  have  been  added  to  event  class  E  since  the  previous 
search,  only  the  latest  one  need  be  checked. 

The  rectangular  event  subspace  and  the  scheme  for  covering  it  as  described  in 
case  1  can  be  used  in  this  case  with  some  additional  information.  In  the  most  general  case 
in  which  the  where  clause  contains  several  instances  of  each  predicate,  we  need  to  keep 
for  each  first  (last)  predicate  the  index  of  the  most  recently  selected  event  (or  reference 
to  that  event  object  if  indexes  are  not  directly  available),  and  for  each  min  (max) 
predicate,  the  latest  minimum  (maximum)  value.  No  information  should  be  kept  for  the 
predicates  exist  or  none. 

While  examining  points  in  the  event  subspace  increment  the  arguments  of  min 
(max)  predicates  are  evaluated  and  the  values  are  compared  with  those  kept  from  previous 
searches.  Similarly,  indexes  can  be  compared  for  first  (last)  predicates.  However,  since  In 
general  the  event  lists  are  not  implemented  as  contiguous  arrays,  the  index  information  Is 
not  available  implicitly  easily.  There  Is  no  need  in  keeping  this  information  explicitly  within 
the  event  objects.  For  example,  if  an  event  list  is  implemented  as  a  doubly  linked  list 
references  to  the  event  objects  can  be  kept  (instead  of  indexes),  and  by  comparing  event 
object  references  to  those  kept  the  same  results  can  be  obtained. 
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In  this  case,  the  number  of  EHM  messages  M  needed  for  covering  the  event 

subspace  increment  containing  the  event  collections  added  between  two  consecutive 

searches  is  at  most  FI  (Nj+dj)  -  FI  Nj  (where  Nj  and  d(  have  the  same  meanings  as  in  case 
1  i 

1);  i.e.,  at  most  the  number  of  event  collections  in  the  event  subspace  Increment.  The 
inequality  stems  from  cases  (such  as  those  described  earlier)  in  which  not  all  new  points  in 
the  event  subspace  increment  need  be  checked. 

The  above  bound  on  M  assumes  that  the  EHM  keeps  pointers  to  all  the  points  in 
matching  event  collections  (having  optimum  values)  in  the  event  subspace  Increment  during 
the  search.  After  the  search  is  completed  instances  of  the  event  handler  are  activated. 
Another  approach,  in  which  the  EHM  only  keeps  the  optimum  values,  requires  a  second 
search  of  the  event  subspace  Increment.  In  the  second  search,  event  collections 
corresponding  to  the  optimum  values  found  In  the  first  search  are  looked  for. 

7.6.5  Case  4:  Single_us©  Event  Handler  with  Predicates 

This  case  deals  with  a  single_use  event  handler  with  at  least  one  predicate  in  its 
where  clause.  The  main  difference  between  this  case  and  case  3  Is  that  here,  once  an 
event  collection  is  selected  and  its  slngle_use  events  are  used,  a  part  of  the  event  space 
Is  deleted  and  event  collections  that  did  not  match  the  event  handier  heading  in  the  past 
may  match  the  heading  now.  (For  example,  an  event  may  satisfy  a  min  predicate  after  an 
event  with  a  smaller  parameter  value  is  used.)  It  follows  that  in  the  general  case  points  in 


the  event  space  must  be  revisited. 
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The  concept  of  the  rectangular  event  aubepace  can  be  ueed  here  also.  Each 
time  the  EHM  starts  an  iteration,  the  boundaries  of  the  current  event  space  are  found  (only 
points  in  this  rectangular  event  subspace  are  checked  In  this  Iteration),  and  the  exist  and 
none  predicates  are  evaluated  as  in  case  3;  only  If  they  are  all  satisfied  the  search  begins. 
During  the  search  event  collections  are  checked  as  in  case  3.  One  difference,  however.  Is 
that  here  the  whole  rectangular  event  subspace  is  searched  and  not  only  the  event 
subspace  Increment,  In  contrast  to  case  3.  Once  a  matching  event  collection  Is  found  it  Is 
treated  as  in  case  2.  After  an  instance  of  the  event  handler  is  activated  and  a  part  of  the 
event  subspace  is  deleted,  the  search  of  the  remaining  part  of  the  (previously  found) 
rectangular  event  subspace  should  restart  in  the  general  case. 

Let  N|  be  the  number  of  existing  events  In  event  list  i  when  the  current  search 
begins.  The  number  of  EHM  messages  M  needed  for  searching  the  rectangular  event 
subspace  until  a  matching  event  collection  is  found  is  at  most  II  N|.  One  reason  for  the 
Inequality  Is  that  in  many  cases  an  optimum  may  be  found  without  searching  the  whole 
rectangular  event  subspace.  Another  reason  is  the  deletion  of  parts  of  the  rectangular 
event  subspace  if  relevant  single_use  events  are  used  by  other  EHM's.  In  order  to  find  out 
how  many  event  collections  D  are  deleted  from  the  rectangular  event  subspace  when  a 
aingle_usa  event  ek  from  event  list  k  Is  used,  the  following  algorithm  can  be  applied: 

D  ■  max  ( 17  N|,  l);  set  for  later  applications  of  this  algorithm. 

I#k 

If  ek  Is  used  by  another  EHM  then  M  Is  decreased  by  at  most  D. 

In  spite  of  the  above,  there  are  Important  cases  in  which  there  is  no  need  to 
restart  searching  the  rectangular  event  subspace  and  the  search  may  simply  proceed. 
First,  observe  that  the  predicates  exist  and  none  have  nothing  to  do  with  restarting  the 
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search;  thalr  treatment  was  analyzed  earlier.  If  there  are  no  adn  or  max  predicates.  La.,  if 
the  where  clause  contains  any  combination  of  the  predicates:  first,  lest,  exist,  and  none 
the  order  of  the  search  In  each  event  fist  is  determined  from  the  first  (lest)  predicates.  The 
order  Is  forward  (backward)  for  each  event  class  Identifier  which  appears  as  an  argument 
of  the  predicate  first  (last). 

If  the  argument  of  each  min  (max)  predicate  ia  a  function  of  the  formal 
parameters  of  one  event  descriptor,  an  Index  for  the  event  list  can  be  created  which  orders 
the  event  objects  according  to  the  function's  value.  The  index  can  be  maintained  by  the 
ECM  which  manages  the  event  list.  In  this  case,  the  order  of  searching  the  event  list  is 
determined  from  the  index.  In  general,  ordering  the  event  list  itself  acoordhtg  to  the 
function  is  not  possible  since  different  event  handlers  may  have  different  functions  for  the 
same  event  class.  The  tradeoffs  involved  in  sorting  an  event  list  are  discussed  in  section 
7.12.1. 


The  use  of  an  index  can  be  generalized  to  a  case  where  the  argument  of  a  ads 
(max)  predicate  involves  formal  parameters  of  k£1  event  descriptors.  A  combined  Index, 
whose  elements  point  to  event  collections  and  not  simply  to  event  objects  (each  element 
contains  k  references),  can  be  created.  The  combined  index  can  be  maintained  by  one  of 
the  k  relevant  ECM's,  or  by  the  EHM.  If  each  event  list  contains  n  event  objects,  the  size 
of  such  an  index  Is  proportional  to  k*nlt.  In  addition  to  this  space  overhead  there  is  a  time 
overhead  associated  with  the  maintenance  of  an  Index.  It  seems  that  in  general,  die  time 
saving  obtained  by  using  a  combined  index  is  not  justified,  except  possibly  for  very  small 
values  of  k,  or  when  time  performance  is  of  prime  Importance.  Update  of  an  index  can  be 
done  when  the  event  lists  change  or  each  time  the  EHM  begins  the  searches. 
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In  the  above  Important  cases,  the  search  can  proceed  after  an  event  collection 
is  found  and  used.  Moreover,  after  the  search  of  the  current  rectangular  event  subspace  Is 
completed  and  all  possible  matching  event  collections  are  found  and  used,  there  Is  no  need 
to  check  again  points  in  this  rectangular  event  subspece  In  future  Iterations  of  the  EHM. 
The  above  observation  means  that  in  each  iteration  of  the  EHM  only  the  event  subspece 
increment  needs  to  be  covered  and  not  the  whole  rectangular  event  subspace  as  In  the 
general  case.  The  number  of  EHM  messages  M  needed  for  covering  the  event  subspace 
increment  containing  the  event  collections  added  between  two  consecutive  iterations  is 
determined  as  in  case  2. 

7.7  Current  Event  Space  Boundaries 

An  EHM  has  to  find  the  current  boundaries  of  the  event  space  before  it  begins 
the  search,  in  cases  1-3  (and  in  case  4  when  it  can  be  handled  by  searching  event 
subspace  increments)  the  current  boundaries  together  with  the  boundaries  found  in  the 
previous  search  define  the  event  subspace  increment  to  be  currently  searched.  In  case  4 
(In  general),  the  current  boundaries  define  the  the  rectangular  event  subspace  to  be 
currently  searched. 

So  far  we  have  intentionally  Ignored  the  question:  how  are  the  current  boundaries 
of  the  event  space  found?  The  question  Is  not  relevant  to  an  event  handler  without 
predicates  (cases  1  and  2)  in  which  case  the  where  clause  defines  properties  of  the  event 
collection  which  are  independent  of  any  other  event.  Since  these  properties  do  not  change 
in  time,  the  only  requirement  from  the  EHM  in  those  cases  is  to  correctly  cover  the  event 
subspace  Increments  it  finds.  For  an  event  handler  with  predicates  (cases  3  and  4),  the 
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EHM  should  compare  properties  of,  possibly,  all  events  In  the  currently  checked  event 
subspace  and  accordingly  decide  in  which  order  to  activate  Instances  of  the  event  handler. 
These  properties  change  in  time;  therefore,  an  EHM  which  performs  the  search  in  nonzero 
time  (as  unfortunately  all  EHM's  do)  may  select  incorrect  event  collections  unless  several 
precautions  are  taken.  The  first  precaution  (which  is  insufficient)  is  to  find  all  boundaries  at 
exactly  the  same  point  in  time. 

The  action  of  finding  the  boundaries  cannot  be  implemented  simply  as  a  sequence 
of  actions  reading  the  needed  values  since  a  set  of  values  inconsistent  with  each  other 
may  be  obtained.  As  an  example  consider  the  following  event  handler  heading: 

on  E1  (I:  hit)  a  E2  (J:  hit)  where  min  (i+J) 

Imagine  that  at  some  point  in  time  three  events  from  the  classes  Ej,  E2  exist:  E j(20), 
Ej(10),  and  E2(5).  The  above  events  have  been  caused  after  the  previous  EHM  search  has 
ended,  and  they  are  ordered  as  follows:  E^(20)  — c->  E^(10),  and  E^(10)  --c->  E2(6).  A 
naive  sequential  algorithm,  which  first  finds  the  boundary  of  the  event  list  associated  with 
E-j  and  then  finds  the  boundary  of  the  event  list  associated  with  E2,  may  return  as 
boundaries  references  to  E-|(20)  and  E2(5).  These  boundaries  are  inconsistent  with  the 
causality  (or  the  precedes)  relation  because  E^(10)  would  not  be  included.  If  event 
collections  containing  E2(5)  are  included  in  the  search  then  event  collections  containing 
E-|(10)  must  also  be  Included  In  the  search  since  E.j(10)  — p->  E2(5).  An  Instance  of  the 
event  handler  would  be  activated  for  the  event  collection  {Ej  (20),  E2(5)}  instead  of  for 
{E^IO),  E2(5)>. 
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Is  it  sufficient  to  sample  all  boundaries  at  the  same  point  in  time?  The  following 
example  gives  a  negative  reply  by  demonstrating  that  the  predicates  exist  or  none 
(together  with  other  predicates)  may  cause  certain  anomalies  if  not  handled  correctly. 
Consider  the  event  handler  heading: 

on  Ej  (i:  int)  a  E2  (j:  int)  where  min  (l+j)  a  exist  (Eg) 

Imagine  that  at  some  point  in  time  four  events  of  classes  E  j ,  Eg,  and  Eg  exist,  ordered  as 
follows:  E-j(IO)  — p->  Eg(20),  Eg(20)  ~p->  E2(10),  and  E2(10)  ~p->  Eg(6);  these  events 
have  been  caused  after  the  previous  EHM  search  has  ended.  An  improved  EHM  algorithm 
may  sample  the  boundaries  of  the  lists  associated  with  E-|  and  Eg  at  exactly  the  same  point 
in  time  and  return  as  boundaries  references  to  Ej(10)  and  Eg(20)  which  are  consistent  with 
the  precedes  relation.  However,  the  EHM  may  then  naively  proceed  and  check  the  value  of 
exist(Eg)  and  get  the  result  true.  The  boundaries  together  with  the  value  of  the  exist 
predicate  are  inconsistent  with  the  precedes  relation.  If  the  value  of  exist(Eg)  is  true  then 
event  collections  containing  E2(10)  must  also  be  included  in  the  search  since 
E2(10)  — p->  Eg(5).  An  instance  of  the  event  handler  would  be  activated  for  the  event 
collection  {E^(10),  E2(20)}  instead  of  for  (E^(10),  E2(10)}. 

The  problem  is  therefore  that  of  Implementing  an  action  sampling  the  event  space 
boundaries  and  the  values  of  the  exist  and  none  predicates  at  exactly  the  same  point  in 
time.  The  difficulty  of  course  stems  from  the  fact  that  the  system  is  distributed  without  any 
centralized  control.  Several  strategies  can  be  used  to  correctly  implement  this  action. 

(1)  Locks 

An  obvious  strategy  is  based  on  locks:  the  EHM  locks  (by  shared  locks)  the 
needed  ECM's  (more  precisely  their  event  lists)  and  then  reads  all  the  needed  values 
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(sequentially  or  concurrently).  The  locking  can  be  Implemented  analogously  to  our 

acquisition  algorithm.  Deadlocks  among  EHM's  trying  to  read  event  subspace  boundaries 

»• 

cannot  happen  since  they  use  shared  locks  only.  However,  deadlocks  Involving  also  EHM’s 
executing  tfie  acquisition  algorithm  can  happen.  More  generally,  deadlocks  involving 
requestors  which  only  try  to  lock  object  classes  for  read  (by  shared  locks)  cannot  occur. 
However,  deadlocks  involving  also  requestors  which  try  to  lock  objects  for  update  (by  write 
locks)  can  occur.  For  example,  if  requestor  R1  tries  to  lock  (for  write)  objects  from  object 
classes  01  and  02  and  requestor  R2  tries  to  lock  (for  read)  coject  classes  and  02  a 
deadlock  can  occur. 

Such  deadlocks  can  be  prevented  by  slightly  modifying  the  relaxed  acquisition 
algorithm  presented  in  section  7.4.  The  graph  G  has  now  the  form  G  *  (NR,  Nq;  A,  AL)  where 
Nr  Nq  and  A  are  defined  as  in  section  7.4.  The  added  set  of  arcs  A|_  contains  exactly  one 
arc  connecting  R(  and  Oj  if  all  the  following  conditions  are  satisfied: 

A1 .  R|  locks  object  class  Oj  for  reading  some  value  associated  with  that  object  class 
(a  list  boundary  or  a  predicate  value  in  our  case). 

A2.  No  arc  connecting  Rj  and  Oj  exists  In  A. 

A3.  A  Contains  at  least  one  arc  which  is  incident  on  Oj. 

If  object  class  0j  is  only  locked  for  read  (by  shared  locks)  it  cannot  cause  a  deadlock  and 
therefore  there  is  no  reason  to  connect  it  with  a  requestor  R|  by  an  arc;  this  is  the 

justification  for  condition  A3.  The  sets  of  object  classes  . Sn  are  found  as  in  section 

7.4;  a  total  order  is  defined  on  the  elements  (object  classes)  of  each  S|  end  the  union  of 
these  total  orders  defines  a  partial  order  P  on  the  set  of  all  object  classes.  The  locking  rule 
B1 '  of  section  7.4  can  be  used  hare. 
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The  disadvantage  of  the  locking  approach  Is  a  reduced  throughput  since  while 
the  locks  are  held,  the  locked  event  lists  cannot  be  modified;  in  particular,  new  event 
objects  cannot  be  inserted  into  the  locked  event  lists.  (Throughput  can  be  defined  as  the 
total  rate  of  event  occurrences;  although,  a  different  definition  is  used  in  appendix  B.) 

(2)  No-Change  Detection 

In  this  strategy,  the  EHM  Iterates  at  least  twice  through  a  set  of  actions.  In 
each  iteration,  the  EHM  reads  ail  the  needed  values  (sequentially  or  concurrently)  by 
communicating  with  the  ECM's  and  keeps  the  read  values.  It  iterates  until  each  ECM 
Indicates  that  there  have  been  no  relevant  changes  (to  be  defined  shortly)  in  its  event  list 
between  the  current  reading  and  the  immediately  preceding  reading  by  the  same  EHM. 

An  ECM  can  keep  track  of  such  changes  by  allocating  one  bit,  the  change  bit,  for 
each  interested  EHM;  the  interested  EHM’s  are  known  to  the  compiler.  The  change  bit  is 
reset  each  time  the  ECM  answers  a  "read  boundary"  or  "exist?"  request  from  the 
corresponding  EHM.  The  change  bit  is  set  whenever  a  relevant  change  in  the  event  list 
occurs.  If  the  event  class  identifier  appears  in  the  event  descriptor  list,  then  a  relevant 
change  occurs  whenever  an  element  is  inserted  into  the  event  list;  deletion  of  an  element 
need  not  set  the  change  bit,  since  the  EHM  is  interested  only  in  existing  events.  If  the 
event  class  identifier  appears  in  an  argument  of  an  exist  (none)  predicate  then  a  relevant 
change  occurs  whenever  the  list  becomes  empty  (not  empty). 

The  main  advantage  of  this  strategy  is  the  simplicity  of  Its  implementation.  The 
disadvantage  however,  is  that  the  EHM  may  Iterate  forever  (e.g.,  if  events  of  the  relevant 
classes  are  caused  at  a  rate  which  is  higher  than  the  EHM's  iterations  rate). 
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(3)  Timestamps 

in  this  strategy,  an  implicit  timestamp  parameter  is  added  to  each  event  object. 
The  timestamp  is  added  by  the  ECM  when  the  event  arrives.  The  local  (logical)  clocks  of 
the  various  processors  can  be  synchronized  by  the  method  described  in  [La-78].  In  fact, 
for  solving  our  problem  the  required  synchronization  is  relaxed  in  comparison  to  the  one 
required  in  the  genera!  case  described  in  [La-78].  The  only  requirements  for  our  problem 
are: 

1.  The  timestamps  reflect  the  precedes  relation  (and  therefore  the  causality 
relation)  between  events. 

2.  The  timestamps  reflect  the  occurrence  order  implied  by  the  predicates  exist  and 
none. 

In  our  problem  timestamps  are  simply  a  mechanism  for  numbering  of  events  by  monotonically 
increasing  numbers  according  to  the  two  requirements  above.  Thus,  local  clocks  need  not 
be  updated  each  time  a  message  tagged  by  a  timestamp  greater  than  the  local  clock 
arrives,  but  only  when  such  a  message  is  relevant  to  at  least  one  of  the  two  requirements 
above.  This  also  implies  that  not  every  message  needs  to  carry  a  timestamp. 

In  this  strategy,  the  EHM  M(H)  requests  from  the  relevant  ECM's  M(Ej) 
(sequentially  or  concurrently)  the  needed  values.  All  such  requests  are  tagged  by  the  same 
timestamp  tc,  the  current  value  of  the  local  clock  of  P(M(H)).  The  purpose  is  to  sample  the 
needed  values  as  of  time  tQ.  However,  due  to  network  delays  and  clocks  diversity  (i.e.,  lack 
of  perfect  clock  synchronization)  the  requests  may  arrive  to  M(Ej)  at  local  time  t|  which  is 
greater  than  or  smaller  than  tc.  If  tc>t|  (clocks  diversity  dominates  network  delays), 
P(M(E|))  simply  advances  its  local  clock  to  be  at  least  tc,  then  returns  the  current 
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requested  value.  If  however  tc<t(  (either  network  delays  dominate  clocks  diversity  or  vice 
versa),  M(Ej)  is  requested  to  return  some  value  which  existed  at  some  past  point  in  time. 
The  problem  of  maintaining  history  of  values  is  addressed  in  [Re-78]  and  some  of  the  ideas 
there  can  be  used  for  solving  our  problem  which  is  more  specific. 

Let  us  first  analyze  the  current  situation  (tc<t()  for  a  more  general  case  (not 
restricting  ourselves  to  our  specific  requests).  There  are  now  two  possibilities:  either  M(Ej) 
has  the  needed  value,  in  which  case  it  simply  returns  it;  or  the  value  Is  no  longer  available, 
in  which  case  a  "forgotten"  reply  is  returned.  The  replies  are  tagged  by  the  current  clock 
value  of  P(M(Ej))j  therefore,  in  the  latter  case,  P(M(H))  can  increment  its  clock  and  retry. 
The  possibility  of  retries  is  not  encouraging  since  this  strategy  then  suffers  from  the  same 
disadvantage  of  strategy  (2)  (which  has  smaller  overhead  associated  with  it). 

The  likelihood  of  the  need  for  retries  can  be  decreased  if  M(E()  remembers  the 
parts  of  its  history  which  would  otherwise  be  forgotten  for  at  least  tm  physical  time  units, 
where  tm  Is  the  sum  of  the  maximum  network  delay  and  the  maximum  clocks  diversity  (or 
some  estimate  of  this  sum).  Another  (partial)  solution  is  to  try  to  avoid  the  problem:  M(H) 
can  first  advance  its  local  logical  clock  by  some  value  At  which  is  big  enough,  and  only  then 
follow  the  previous  procedure.  Unfortunately,  when  several  EHM's  follow  this  strategy  a 
situation  in  which  tc<t(  may  quickly  arise;  thus,  It  seems  that  the  problem  has  not  been 
solved.  However,  It  is  important  to  observe  that  in  this  case,  logical  time  progresses  faster 
than  physical  time;  the  computation  does  not  progress  faster  (in  physical  time)  just  because 
At  increases.  Therefore,  the  likelihood  that  the  needed  value  is  no  longer  available 
decreases  as  At  Increases. 


Current  Event  Space  Boundaries 


-  151  - 


Section  7.7 


The  previous  discussion  was  general,  and  at  this  point  the  specific  requests  in 
our  implementation  scheme  and  their  Implications  are  analyzed,  in  order  to  answer  an 
"exist?"  request,  the  ECM  can  keep  a  list  of  local  logical  times  at  which  the  state  of  its 
event  list  changes  from  empty  to  not  empty  and  vice  versa.  Old  entries  in  the  list  can  be 
deleted  (after  tm  physical  time  units,  as  discussed  previously),  and  in  addition,  the  list  can 
be  limited  to  contain  at  most  n  entries  (the  latest  change  points)  in  order  to  bound  its 
storage  overhead. 

In  order  to  answer  a  "read  boundary"  request  (with  timestamp  tc),  the  ECM 
simply  returns  a  reference  to  the  latest  existing  event  object  whose  timestamp  te  is  not 
greater  than  tQ.  There  is  no  need  to  keep  any  information  in  addition  to  the  event  list  in 
order  to  treat  the  request.  Even  If  an  event  object  whose  timestamp  te'  satisfying 
te<te'<tc  existed  in  the  past  (and  not  currently),  there  Is  no  need  to  remember  It  since  an 
EHM  is  interested  only  in  existing  event  objects. 

The  behavior  of  the  suggested  timestamp  based  scheme  is  equivalent  to  that 
obtained  by  simultaneously  sampling  all  needed  values  at  a  state  (of  the  relevant  event 
lists)  which  could  exist  at  time  tc.  Due  to  the  fact  that  the  clocks  are  not  perfectly 
synchronized,  this  state  may  have  not  existed  in  reality  but  it  could.  The  user  has  no  way 
of  checking  whether  this  state  Indeed  existed  and  this  scheme  exploits  this  fact. 

The  main  disadvantage  of  this  approach  is  a  higher  storage  overhead;  the 
disadvantages  of  the  first  two  strategies  are  cured  here.  By  selecting  big  enough  values 
for  the  parameters  tm,  n,  at  the  probability  of  a  need  to  retry  can  be  decreased  below  any 
positive  desired  value.  Moreover,  attaching  timestamps  to  event  objects  supports  the 
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following  functions  in  boolean  expressions  (both  in  the  where  clause  and  in  the  script  of 
event  handlers). 

1 .  A  precedes  function  which  indicates  whether  one  event  from  the  event  collection 
precedes  another  one  from  the  same  event  collection;  e.g., 

on  E-,  (i:  int)  a  E2  (j:  int)  where  i>J  and  E-j  (i)  precedes  E2  (j) 

2.  A  time  function  which  returns  the  occurrence  time  of  an  event.  Such  a  function 
can  be  used  not  only  for  specifying  an  order  between  two  events  but  also  for 
specifying  by  how  much  time  one  event  precedes  the  other;  e.g., 

on  E1  (i:  int)  A  E2  (J:  int)  where  l=j  and  (time  (E2  (j))  -  time  (E1  (I))  >  10) 

If  the  above  functions  are  added  to  the  language,  the  relaxed  requirements  for  clock 
synchronization  are  not  sufficient  since  various  anomalies  can  happen.  Assume  for  example 
that  Ej,  E2  are  system  event  class  Identifiers  whose  events  occur  when  buttons  B^,  B2  are 
pressed  respectively.  Assume  that  each  event  from  the  above  classes  activates  an 
instance  of  a  corresponding  event  handler  which  causes  printing  the  event  occurrence  time. 
Suppose  clocks  are  not  sufficiently  synchronized;  then  If  B-|  is  pressed  and  several  seconds 
afterwards  B2  Is  pressed,  it  may  happen  that  the  time  printed  for  B2  Is  smaller  than  that 
corresponding  to  B-j .  Local  clocks  must  be  better  synchronized  to  decrease  the  liklihood  of 
such  anomalies.  The  gerrral  scheme  of  [La-78]  can  be  used;  other  schemes  are  described 
in  [Re-78]. 
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7.8  The  Event  Class  Manager 

An  ECM  maintains  an  event  list  which  contains  event  objects  from  the 
corresponding  event  class.  It  Is  a  process  which  handles  requests  from  EHM's  (e.g.,  "give 
next  event  object"),  and  from  instances  of  event  handlers  (e.g.,  "insert  an  event  object 
into  the  event  !ist").  Each  time  an  event  object  Is  inserted  Into  the  event  list,  the  ECM 
broadcasts  a  message  to  the  relevant  EHM's,  thus  suggesting  that  they  look  for  new 
matching  event  collections.  Each  time  the  event  list  becomes  empty  (not  empty)  it  notifies 
the  EHM's  associated  with  event  handlers  which  include  the  corresponding  event  class 
identifier  as  an  argument  of  a  none  (exist)  predicate. 

7.9  Event  List  Organization 

An  event  list  Is  dynamically  changing.  Elements  can  be  inserted  into  it,  and  in  the 
case  of  single_use  events  elements  can  also  be  deleted  from  it.  We  shall  concentrate  on 
the  latter  case  since  the  former  is  simpler.  The  fact  that  the  memory  associated  with  each 
processor  is  unbounded  allows  us  not  to  do  garbage  collection.  However,  we  shall  not 
exploit  this  since  we  would  like  to  map  this  implementation  scheme  to  more  constrained 
systems.  A  specific  implementation  of  an  event  list  will  be  described  in  order  to  make  the 
following  discussions  more  concrete. 

An  event  list  is  implemented  as  a  doubly  linked  list  with  a  list  head  [Kn-76].  The 
elements  in  the  event  list  are  ordered  according  to  their  arrival  order  to  the  ECM.  In  order 
to  support  the  various  list  operations  needed  to  process  the  requests  from  an  ECM,  a  list 
element  will  be  in  one  of  the  following  states: 
ready:  The  normal  state,  the  element  is  ready  for  booking. 
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booked:  The  element  is  booked  by  an  EHM. 

acquired:  The  element  is  acquired  by  an  EHM;  it  is  logically  out  of  the  list  but  physically  atm 
in  the  list  (i.e.,  it  Is  linked  to  its  neighbors). 
deleted:  The  element  is  both  logically  and  physically  out  of  the  list. 

The  state  of  an  element  changes  according  to  the  diagram  of  Figure  7.6.  The  first  three 
states  support  the  two  phase  acquisition  algorithm  described  earlier.  The  distinction 
between  the  states  acquired  and  deleted  is  needed  since  several  references  to  an 
acquired  element  may  exist  (In  various  EHM's  searching  matching  event  collections). 
Deleting  the  element  from  the  list  and  returning  it  to  the  free  storage  may  cause 
unpredictable  effects.  Deleting  the  element  from  the  list  and  suspending  its  return  to  free 
storage  until  it  is  no  longer  pointed  to  is  not  sufficient  since  it  does  not  allow  simple  tracing 
of  the  elements  of  a  list  until  a  particular  element  (which  can  be  in  the  acquired  state)  is 
reached.  This  operation  is  required  in  our  implementation  scheme  when  searching  the  event 
subspace;  the  particular  element  is  for  example  a  boundary  element. 


deleted 

Figure  7.6  State  diagram  of  a  Nat  element 


In  order  to  support  the  transfer  from  the  acquired  state  to  the  deleted  state  a 
reference  count  mechanism  is  used  [Kn-76].  Each  Rst  element  contains  a  reference  count 
field  which  counts  the  number  of  references  pointing  to  It  from  EHM's.  The  reference  count 
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is  updated  when  requests  from  EHM's  are  processed.  It  should  be  noted  that  the  reference 
count  mechanism  is  used  to  control  the  deletion  of  elements  from  a  list  and  not  for  garbage 
collection  purposes  as  is  normally  done. 

A  list  element  can  be  returned  to  free  storage  when  the  following  two  conditions 
are  satisfied^ 

1 .  It  is  In  the  deleted  state. 

2.  The  data  it  carries  Is  no  longer  needed;  i.e.,  the  instance  of  the  event  handler 
which  uses  it  obtained  all  the  data  it  requires. 

Since  the  above  conditions  can  be  satisfied  in  any  order,  an  additional  bit  not-neodad  is 
required;  this  bit  specifies  whether  a  message  saying  that  the  element's  contents  Is  no 
longer  needed  (and  therefore  can  be  returned  to  free  storage  after  it  enters  the  deleted 
state)  has  been  received.  Manipulation  of  the  above  conditions  causes  no  synchronization 
problems  since  it  is  performed  by  one  processor  (on  which  the  ECM  resides).  If  the  event 
list  is  maintained  in  a  shared  memory  (directly  accessible  to  several  processors),  existence 
of  an  appropriate  test  and  set  nondlvisible  instruction  is  sufficient  for  correct  manipulation 
of  the  above  conditions. 

The  fact  that  reference  counts  are  used  not  for  garbage  collection  causes  some 
slight  variations  from  the  classical  approach.  The  reference  count  mechanism  should  detect 
a  situation  in  which  an  acquired  list  element  can  be  deleted  as  early  as  possible  in  order  to 
decrease  the  overhead  while  scanning  the  list.  For  this  reason,  only  references  from  EHM's 
are  counted;  references  to  a  list  element  from  an  Instance  of  an  event  handler  are  not 
counted.  The  structure  of  an  Instance  of  an  event  handler  is  known  to  the  compiler,  which 
knows  in  particular  how  many  times  each  event  object  is  referenced  In  the  script. 


Section  7.8 


-  160  - 


Event  List  Organization 


Therefore,  an  explicit  message  indicating  that  the  event  object  is  no  longer  needed  can  be 
sent  by  the  Instance  of  the  event  handler  (regardless  of  the  reference  count  value). 

An  alternative  approach  In  which  all  references  to  a  list  element  are  counted  Is 
semantically  cleaner,  however,  It  causes  a  redundant  overhead  as  was  explained  earlier; 
that  is  the  reason  why  the  more  standard  approach  was  slightly  modified  here.  In  both 
approaches,  the  problem  of  objects  which  are  not  reclaimed  due  to  cycles  cannot  occur 
since  only  references  from  objects  which  are  not  handled  by  the  reference  count 
mechanism  are  counted.  One  should  note  that  nothing  prevents  an  EHM  from  copying  a  list 
element  reference.  Such  a  copying  Is  preceded  by  an  explicit  request  to  increment  the 
reference  count  when  needed;  e.g.,  when  a  reference  to  the  boundary  of  the  previous 
rectangular  event  space  Is  copied  to  the  pointer  to  the  current  list  element.  In  some  cases 
the  explicit  Incrementing  Is  not  needed;  e.g.,  when  a  Hat  element  reference  Is  passed  to  an 
instance  of  an  event  handler.  The  decision  whether  to  explicitly  increment  the  reference 
count  is  made  by  the  compiler. 

7.10  Bequests  from  an  ECM 

The  ECM  keeps  requests  from  various  sources  in  a  request  queue  and  processes 
them  one  at  a  time  (although  handling  a  request  may  be  suspended).  This  section  describes 
the  main  requests  that  a  typical  ECM  may  be  required  to  handle.  The  possible  requests 
issued  by  an  instance  of  an  event  handler  are: 

Insert:  Inserts  an  event  object  Into  the  the  event  list;  at  Its  end. 

not-needed:  Indicates  that  the  list  element  Is  no  longer  needed  by  the  Instance  of  the 

event  handler  and  Its  not-needed  bit  can  be  set. 
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reach  Reads  all  or  some  of  the  parameters  of  a  list  element.  This  request  can  also  be 
issued  by  an  EHM. 

The  possible  requests  issued  by  an  EHM  are: 

book:  Books  an  event  list  element.  The  execution  of  this  request  may  be  suspended  If 

the  list  element  is  currently  booked. 
cancel:  Cancels  a  previous  booking  of  an  event  list  element. 

acquire:  Acquires  an  event  list  element  which  was  previously  booked. 
next:  Returns  the  next  element  (satisfying  some  condition)  in  an  event  list.  The 

execution  of  this  request  may  be  suspended  if  the  list  element  to  be  returned  Is 
currently  booked. 

Two  of  the  above  requests  deserve  further  explanation.  The  meaning  of  the  Insert  request 
is  more  complicated  in  the  case  of  non_recurrent  events.  An  ECM  should  verify  that  the 
event  list  does  not  contain  an  object  identical  to  the  object  included  in  the  request  before 
inserting  the  object  into  the  list.  Some  optimization  can  be  used  here  as  discussed  in 
section  7.12.1.  If  the  event  list  is  kept  in  shared  memory,  it  is  possible  that  the  instance  of 
the  event  handler  trying  to  cause  the  event  will  search  the  event  list  itself;  thus 
decreasing  the  load  on  the  ECM.  If  an  identical  element  is  found,  It  aborts  the  trial; 
otherwise,  it  sends  the  insert  request,  indicating  up  to  which  point  it  has  searched  the  list. 
At  that  point  the  ECM,  which  has  exclusive  write  access  to  its  event  fist,  scans  the  rest  of 
the  event  list  (new  elements  may  have  been  added  to  the  list  since  the  instance  of  the 
event  handier  performed  its  search)  and  treats  the  given  element  appropriately. 
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The  next  request  is  a  complex  request  Intended  to  support  event  subspace 
search  by  an  EHM.  The  ECM  searches  an  event  list  within  two  limits  while  performing  some 
checks  on  the  list  elements.  These  checks  could  also  be  performed  by  the  EHM  but  the 
communication  overhead  In  such  a  solution  may  be  high,  especially  for  EHM's  which  are 
interested  only  in  a  small  percentage  of  the  elements  of  a  list.  The  ECM  can  perform  at 
least  an  initial  filtering  of  the  event  list  and  thus  decrease  the  number  of  messages 
exchanged  with  the  EHM.  The  search  starts  at  the  element  following  an  element  specified 
in  the  request  and  proceeds  (forwards  or  backwards  as  specified  in  the  request)  until  an 
element  satisfying  some  condition  is  found  or  the  limit  is  reached. 

The  structure  of  the  condition  Is  limited;  it  is  not  a  general  boolean  expression. 
For  example,  the  condition  can  be  a  simple  boolean  relation  whose  terms  may  refer  to  words 
of  a  list  element  by  denoting  an  offset  from  the  beginning  of  the  element,  or  to  constants; 
e.g.,  according  to  the  following  syntax: 

<condition>  <arg>  <oper>  <arg>  <relatfonal_operator>  0 
<arg>  <constant>  |  <offset> 

<oper>  add  |  sub  |  and  |  xor  | ... 

<relatkxial_operator>  <  |  <•  |  ■  |  <>  J  >■  |  > 

Elements  in  the  acquired  state  are  not  returned  as  results;  they  are  skipped  and 
may  be  deleted,  depending  on  their  reference  count.  The  request  can  specify  that  during 
the  search  reference  counts  should  be  modified  by  a  number  specified  in  the  request;  the 
reference  counts  are  updated  as  references  move  from  one  fist  element  to  another  during 
the  search.  A  special  check  can  be  performed  to  detect  cases  In  which  acquired  elements 
are  pointed  to  only  by  references  given  in  the  request  itself.  If  such  elements  are  found 
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they  ere  deleted  from  the  list.  If  an  element  pointed  to  by  one  of  the  limit  references  is 
deleted  the  limit  reference  retreats;  i.e.,  a  new  limit  reference  pointing  to  a  previous 
element  not  in  the  acquired  state  is  returned  as  one  of  the  request  results. 

An  interesting  question  is:  What  should  an  ECM  do  if  during  preforming  the  next 
request  a  booked  element  is  encountered?  First,  booked  elements  which  do  not  satisfy  the 
search  condition  are  skipped.  The  more  Important  question  is:  how  to  treat  booked  elements 
satisfying  the  condition?  Several  strategies  can  be  employed.  In  the  first,  processing  of 
the  request  is  suspended  until  the  state  of  the  element  changes.  In  the  second,  such 
elements  are  returned  as  results.  The  first  strategy  assumes  that  the  probability  that  the 
EHM  which  has  booked  the  element  will  cancel  the  booking  is  low,  and  therefore  does  not 
return  the  element  to  the  requesting  EHM  in  order  not  to  cause  It  to  do  fruitless  work.  The 
second  strategy  Is  based  on  the  opposite  assumption,  and  it  therefore  returns  even  booked 
elements  as  results.  Both  strategies  are  correct,  but  they  may  yield  different  performance; 
some  experimentation  is  required  in  order  to  choose  among  them. 

During  processing  of  the  next  request,  the  list  head  is  specially  treated  and 
serves  as  an  additional  limit  in  each  direction  of  the  search;  its  reference  count  is  not 
modified.  The  first  (last)  element  of  a  list  can  be  accessed  by  issuing  a  next  request  with 
the  list  head  as  the  current  element  in  the  forward  (backward)  direction.  This  request  can 
be  also  used  for  finding  whether  the  event  list  is  empty.  The  first  element  of  the  list  is 
searched  for,  specifying  that  no  side  effects  are  to  occur  (In  particular,  no  reference  count 
changes).  In  this  case,  booked  elements  do  not  cause  suspending  of  the  request,  since  a 
booked  element  still  exists. 
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7.1 1  Fairness 

So  far  fairness  issues  have  been  intentionally  ignored.  An  Implementation  of  EBL 
must  guarantee  several  faimeas  rules  (F0-F3  of  chapter  2).  The  first  question  is  whether 
the  implementation  scheme  outlined  in  this  chapter  is  fair  or  not.  Unfortunately,  our 
implementation  scheme  only  guarantees  fairness  rule  FO;  each  of  the  other  rules  may  be 
violated.  The  principal  source  of  the  problem  is  contention  among  EHM's  trying  to  acquire 
single_use  events  from  the  same  event  class.  Suppose  EHM  M|  needs  one  event  from  each 
of  the  two  event  classes  Ej  and  E  in  order  to  activate  an  instance  of  the  corresponding 
event  handler  for  i=1,  2;  assume  E  has  a  single_use  type  associated  with  it.  Theoretically, 
M2  may  never  succeed  In  the  acquisition  of  an  event  from  event  class  E  (if  M-j  always  wins) 
and  thus  may  never  use  events  from  event  class  E2  (regardless  of  the  type  of  E2). 
Depending  on  the  rest  of  the  program,  this  situation  can  violate  FI  and  F2. 

For  example,  a  P  operation  (as  described  In  chapter  5)  may  wait  forever  while 
infinitely  many  P  operations  on  the  same  semaphore  variable  successfully  terminate. 
Similarly,  a  reserve  request  in  the  airline  reservation  system  of  chapter  8  may  not  be 
processed  forever.  Such  situations  are  normally  called  starvation  in  process  based  models. 

Fairness  rule  F3  is  guaranteed  In  our  implementation  scheme  for  multi_use  event 
handlers  without  predicates.  The  rule  is  not  guaranteed,  however,  for  multi_use  event 
handlers  with  predicates.  The  problem  arises  when  an  exist  (none)  predicate  contains  as  an 
argument  a  single_usa  event  class  Identifier.  The  predicate  may  be  satisfied  In  infinitely 
many  periods  of  the  clock  (which  Is  used  In  the  fairness  rules  definitions),  each  time  for  a 
short  duration.  An  EHM  may  be  too  slow  to  begin  the  search  while  the  predicate  is  satisfied; 
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it  therefore  may  nevdr  use  event  collections  thus  violating  F3. 

The  problem  can  be  easily  eliminated  by  associating  timestamps  with  events  (as 
suggested  for  finding  event  space  boundaries).  An  EHM  can  examine  the  value  of  the 
predicate  at  some  past  point  and  if  it  is  satisfied  perform  the  search  on  the  event  space 
which  existed  at  that  time.  The  same  problem  may  arise  in  case  of  single_use  event 
handlers;  the  above  scheme  can  be  applied  here.  The  following  scheme  for  guaranteeing 
rules  F1-F2  can  solve  this  problem  too  (for  both  types  of  event  handlers). 

The  fundamental  idea  Is  that  each  EHM  M(H)  should  detect  a  case  in  which  it 
could  use  an  event  e  in  many  opportunities  (possibly  together  with  some  other  events)  but  it 
failed  to  do  so  due  to  some  race  condition.  If  H  does  not  contain  predicates  then  the  only 
reason  for  a  failure  of  M(H)  is  that  events  from  certain  single_use  event  classes  are  used 
by  other  EHM's.  If  H  contains  predicates  then  an  additional  reason  is  that  predicates  may  be 
satisfied  for  short  periods  of  time  which  are  insufficient  for  M(H)  to  select  and  acquire  the 
needed  events.  When  M(H)  detects  that  it  failed  in  a  race  it  acts  to  increase  the  likelihood 
that  it  wins  a  similar  race  in  the  future.  It  basically  notifies  the  relevant  ECM's  so  that  they 
can  prefer  it  in  the  future. 

In  order  to  allow  EHM’s  to  detect  cases  in  which  they  lose,  the  behavior  of  ECM's 
must  be  modified.  An  ECM  should  not  delete  an  event  from  the  event  list  immediately  when 
possible,  but  rather,  delay  the  deletion  for  a  period  of  time  T,  which  Is  long  enough  to  enable 
EHM's  to  detect  that  they  could  use  the  event.  T  can  be  dynamically  changed  according  to 
the  sizes  of  the  event  spaces  associated  with  the  relevant  EHM's.  When  an  ECM 


processes  the  next  request  It  does  not  skip  over  acquired  event  objects  and  does  not 
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suspend  the  processing  when  a  booked  event  object  is  encountered.  When  an  acquired 
event  Is  thus  returned  it  Is  marked  as  acquired ;  the  EHM  checks  if  it  could  use  such  an 
event  but  it  does  not  try  to  acquire  it. 

What  should  M(H)  do  when  it  ejects  that  it  failed?  Suppose  M(H)  finds  out  that 
event  class  E  is  one  of  the  reasons  to  the  failure.  M(H)  can  then  increment  a  counter  (a 
failure  counter)  CHE  associated  with  the  pair  of  managers  M(H)  M(E)  and  let  M(E)  know  the 
new  value.  M(E)  knows  the  values  of  ail  relevant  counters  and  can  give  a  higher  priority  to 
requests  associated  with  EHM  M(H)  whose  failure  counter  has  the  highest  value.  This  higher 
priority  is  not  sufficient  since  requests  from  M(H)  may  arrive  too  late  to  be  served.  After 
M(£)  notifies  EHM's  about  a  change  in  its  event  list  it  restricts  further  changes  in  the  list  for 
a  period  of  time  T1.  During  this  period,  only  changes  resulting  from  requests  made  by  M(H) 
are  allowed.  After  this  period,  changes  are  ordered  according  to  failure  counters.  T1  can  be 
dynamically  changed  as  T  above. 

Let  us  give  some  details  of  a  scheme  for  dynamically  evaluating  T'  and 
manipulating  the  failure  counters.  Other  schemes,  perhaps  more  efficient,  are  possible  and 
we  describe  this  one  only  as  n  concrete  example.  In  this  scheme  if  M(H)  finds  during  a 
search  of  its  event  subspace  that  it  failed  due  to  M(E)  it  increments  CHE  by  1.  Failure 
counters  are  not  decremented  (although  other  strategies  are  possible). 

Suppose  a  single_use  event  class  identifier  E  appears  in  the  headings  of  event 
handlers  H-j,  ...  ,  Hn.  If  a  new  event  is  added  to  the  event  list  associated  with  M(E)  at  time 

tQ,  M(fcj  sends  messages  to  M(Hj) . M(Hn)  and  waits  T'  time  units  as  described  earlier. 

During  the  T'  time  units  all  above  managers  should  be  able  to  perform  searches  of  their 
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event  spaces  (other  schemes  are  possible).  After  that  interval  M(E)  selects  M(H)  whose 
counter  has  the  maximum  value  among  all  managers  that  have  requested  to  book  events  of 
MCE). 

T'  can  be  found  as  follows.  The  message  sent  by  M(E)  has  first  to  propagate  to 
all  M(H|)  above.  A  bound  on  this  propagation  time  Is  A  .j ,  the  maximum  network  delay,  which 
we  assume  is  known.  Each  M(H,)  then  finds  the  boundaries  of  its  event  space  as  of  a  time 
no  later  than  tQ+A2,  and  then  searches  the  event  subspace.  A2  is  q  bound  which  can  be 
derived  from  A 1  and  exact  parameters  of  the  algorithm  for  finding  event  space  boundaries. 

Each  time  there  is  a  change  In  one  of  the  event  lists  associated  with  an  event 
class  identifier  Ej  (which  appears  in  the  heading  of  Hj)  the  new  size  (number  of  event 
objects)  Sj  of  that  list  Is  sent  to  M(E).  Due  to  network  delay,  at  time  M(E)  knows  each  Sj 
as  of  a  point  in  time  tj,  where  tQ-t1  <  A1 .  The  actual  size  of  the  event  list  associated  with 
Ej  that  each  EHM  may  have  to  scan  can  Increase  in  the  interval  A1 +A2  by  at  most 
ASj  =  (A  1  +a2)Rj.  Rj  is  the  maximum  rate  in  which  events  can  be  added  to  the  event  list 
associated  with  Ej.  It  can  be  found  from  the  maximum  processor  speed  which  we  assume  is 
known.  M(Hf)  may  have  to  scan  up  to  Sj+ASj  events  from  the  event  list  associated  with  Ej. 
The  time  required  by  M(Hj)  to  complete  the  search  is  bounded  by  Tj  *  Kj  1~I  (S.+AS:)  where  j 

J 

ranges  over  event  class  identifiers  appearing  in  the  event  descriptor  list  of  H|.  depends 
on  the  heading  of  H|,  and  on  the  minimum  processor  speed  which  we  assume  is  known. 
Since  T'  should  allow  all  managers  M(Hj)  to  complete  their  searches,  T'  >  Aj+max  (T |)  is 
appropriate.  (The  term  A^  in  the  above  Inequality  represents  the  propagation  time  of  the 
original  message  sent  by  M(E).) 
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Smaller  values  can  be  selected  for  T1  in  many  cases.  For  example,  If  formal 
parameters  associated  with  event  class  identifier  Ej  do  not  appear  in  the  where  clause  of  H| 
then  Sj+ASj  can  be  replaced  by  1  in  Tj.  As  a  consequence,  if  H|  has  no  where  clause  then  T| 
is  replaced  by  Kj. 

As  an  example  of  the  way  the  failure  counters  work  consider  the  following 
program  which  consists  of  four  event  handlers: 

S,  L-|,  L2,  L3:  single_use  recurrent  event  ; 

on  program_start 

seq_cause  L1 ;  L2i  Lg;  S 
end  ; 

{  Event  handler  H|  (1=1, 2,3)  } 
on  L,  a  S  {  a  P  operation  } 

seq_cause  ;  S  ;  Lj 
end  ; 

The  three  event  handlers  Hj,  H2,  Hg  correspond  to  three  concurrent  processes  of  the  form: 

L|:  P  (S)  ;  {  a  P  operation  on  S } 

V  (S)  ;  {  a  V  operation  on  S  } 

goto  Lj 

We  can  easily  show  that  every  event  In  event  class  Lj  Is  eventually  used;  thus, 
none  of  the  three  corresponding  processes  can  starve.  It  is  not  possible  that  a  single  EHM, 
say  M(H|),  always  wins  (succeeds  to  acquire  an  event  from  event  class  S  each  time  such  an 
event  exists).  The  value  of  the  counter  C^g  associated  with  M(H|)  remains  constant 
whereas  the  values  of  the  counters  associated  with  the  other  two  EHM's  increase  each 
time  an  event  of  class  S  is  used.  Eventually  the  value  of  the  counter  associated  with 
another  EHM  becomes  bigger  than  that  of  C^g,  and  at  that  time  M(H|)  does  not  win  but 
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another  EHM  wins.  Similarly,  it  is  not  possible  that  each  time  an  EHM  wins  it  is  one  of  two 
EHM's,  say  M(H|)  or  M(Hj),  whereas  the  remaining  EHM  MCH^)  never  wins  (i.e.,  starves).  The 
reason  is  that  the  rate  In  which  each  of  the  two  counters  C^g  ChjS  13  Incremented  is  leas 
than  once  per  use  of  an  event  from  class  S  (since  none  of  the  two  EHM's  always  wins  as 
was  shown  earlier).  On  the  other  hand,  CH^g  ls  Incremented  by  1  after  each  use  of  an 
event  from  class  S  (since  M(H|l)  always  loses).  Eventually  the  value  of  the  counter  CH^g 
becomes  the  biggest  and  M(H|()  succeeds  to  acquire  the  next  event  from  class  S.  The 
case  in  which  none  of  the  three  EHM's  ever  wins  is  ruled  out  by  our  scheme  since  each  time 
an  event  from  event  class  S  exists  one  of  the  three  EHM's  acquires  it. 

A  nondetermlnistic  state  diagram  can  be  drawn  as  shown  in  Figure  7.6.  Each 
state  in  this  diagram  describes  the  values  of  the  three  counters  CH^  s,  C^g,  C^g  relative 
to  the  value  of  the  counter  having  the  smallest  value  at  that  state.  We  assume  the  initial 
value  of  each  of  the  three  counters  is  0.  A  transition  from  state  Sj  to  state  in  the 
diagram  is  labeled  by  the  subscript  i  of  the  winner  M(H|)  in  state  Sj. 


Figure  7.6  Stats  diagram  with  failure  counters 
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The  intentional  delay  Introduced  by  an  ECM  and  the  additional  proceaslng  done  by 
managers  to  achieve  a  fair  implementation  may  cause  performance  degradation.  The 
scheme  can  be  Improved.  There  are  cases  in  which  M(H)  needs  from  M(E)  only  events 
satisfying  some  condition.  For  example,  in  the  airline  reservation  system  of  chapter  6  an 
EHM  may  need  the  counter  associated  with  a  certain  flight.  In  such  cases,  M(E)  can 
remember  the  needed  condition  and  introduce  the  delay  period  T*  only  when  the  appropriate 
condition  Is  satisfied. 

An  EHM  should  repeatedly  try  to  Include  each  existing  event  in  event  collections 
it  examines  (unless  it  knows  that  the  event  cannot  participate  in  any  matching  event 
collection).  Otherwise,  the  scheme  presented  above  does  not  guarantee  fairness  rules 
F1-F2.  This  requirement  (from  an  EHM)  does  not  pose  serious  difficulties.  Each  EHM  should 
examine  single__use  events  from  each  relevant  event  class  E  in  the  order  in  which  they 
arrive  to  M(E)  (unless  E  appears  in  a  last  predicate  in  the  heading  of  H). 

Events  of  multi_use  types  should  be  treated  differently.  Consider  an  event 
handler  whose  heading  has  the  form: 

on  E-j  (...)  a  E^  (•••) 

Suppose  the  types  associated  with  E-j  and  Eg  are  slngle_use  event  and  multi_use  event 
respectively,  if  events  from  event  class  Eg  are  examined  in  the  order  in  which  they  arrive 
to  M(Eg)  it  may  happen  that  only  the  first  event  in  the  list  is  selected  for  matching  event 
collections  while  other  events  are  never  selected. 

in  order  to  eliminate  such  anomalies,  in  each  search  performed  by  an  EHM  M(H) 
the  first  event  to  be  examined  from  a  multi-use  event  class  E  can  be  selected  according 


irr 


Fairness  -  167  -  Section  7.1 1 

to  some  round  robin  order  (on  the  events  of  event  class  E).  In  addition,  the  multi_uae  event 
class  whose  events  are  examined  first  In  the  search  can  be  selected  according  to  some 
round  robin  order  (on  the  mutti_use  event  classes  appearing  In  the  event  descriptor  list  of 
H).  Finally,  suppose  H  contains  In  Its  event  descriptor  list  event  class  identifiers  of 
muiti_use  and  slngle_use  event  types.  M(H)  examines  event  collections  by  trying  to 
match  all  possible  combinations  of  single_use  events  to  one  combination  of  muttl_use 
events,  then  Iterates  for  another  combination  of  multi_use  events  etc. 

Note  that  the  modifications  in  the  implementation  scheme  suggested  In  this 
section  do  net  introduce  possibilities  for  deadlocks  involving  managers  since  timeouts  are 
associated  with  the  various  waiting  periods  introduced  above.  The  only  negative  effect  of 
the  modification  is  performance  degradation;  this  is  the  price  paid  for  achieving  a  fair 
implementation. 

7.12  Optimizations 

There  are  several  sources  for  optimization  in  an  EBL  program.  The  simplest  one  is 
common  subexpression  elimination.  This  optimization  can  be  applied  both  to  the  script  of  an 
event  handler  and  to  the  boolean  expression  In  the  where  clause  of  an  event  handler  by 
well  known  techniques  [Ah-77].  Other  sources  for  optimization  are  derived  from  the  unique 
semantics  of  the  language  and  some  of  them  are  analyzed  next.  These  optimizations  should 
be  viewed  as  compiler  options  which  can  be  Individually  selected  by  the  user.  The  degree 
of  effort  to  be  invested  in  each  selected  optimization  can  be  another  parameter  specified 
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The  basic  event  list  organization  suggested  in  previous  sections  wee  a  doubly 
linked  list  ordered  according  to  the  arrival  order  of  event  objects  to  the  ECM.  However, 
there  are  cases  which  are  easily  detected  by  the  compiler,  in  which  this  data  structure  can 
be  either  improved  or  a  totally  different  organization  selected.  The  optimization  Is  based  on 
the  where  clauses  of  event  handlers  containing  the  event  class  identifier  in  their  headings, 
as  well  as  on  the  type  of  the  event  clsss  identifier. 

7.12.1  Sorting  an  Event  List 

There  are  several  reasons  for  sorting  an  event  list.  One  reason,  which  has 
already  been  mentioned,  is  for  preventing  revisiting  of  an  event  collection  In  case  of  a 
single_use  event  handler  with  predicates.  An  event  list  can  be  sorted  according  to  one  or 
more  keys  (by  creating  indexes).  If  a  where  clause  contains  a  min  or  awx  predicate  whose 
argument  is  a  function  of  the  formal  parameters  associated  with  that  event  class  Identifier, 
sorting  the  event  list  according  to  that  function  can  result  in  a  better  performanesL  The  list 
itself  can  be  sorted  according  to  the  function  only  if  there  is  only  one  such  function 
associated  with  the  event  class  Identifier,  and  the  predicates  first  or  last  are  not 
associated  with  the  event  class  identifier  in  the  whole  progrsm.  If  the  list  itself  cannot  be 
sorted,  multiple  Indexes  can  be  created  which  effectively  sort  the  event  list  according  to 
the  functions. 

What  are  the  tradeoffs  involved  In  sorting  sn  event  list?  Suppose  EHM  M(H) 
wishes  to  find  an  event  satisfying  some  min  predicate  from  ECM  M(E).  Let  n  be  the  number 
of  objects  in  the  event  list.  In  the  most  straightforward  scheme,  M(H)  finds  the  desired 
object  by  sending  n  messages  to  M(E);  each  message  requests  the  next  object.  The  total 
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number  of  message*  is  2n.  This  scheme  can  be  improved  by  allowing  M(H)  to  request  all 
objects  in  one  message.  The  total  number  of  messages  in  this  case  is  reduced  to  n+1 .  A 
further  reduction  in  the  number  of  messages  required  can  be  achieved  if  M(E)  itself  finds 
the  desired  object,  in  this  case,  the  total  number  of  messages  is  reduced  to  2, 
independently  on  n.  The  structure  of  the  predicate  need  not  be  sent  from  M(H)  to  M(E);  the 
compiler  can  supply  the  information  to  M(E).  M(H)  can  be  required  at  most  to  supply  the 
values  of  some  other  events'  parameters. 

Thus,  in  order  to  reduce  communication  overhead  an  event  list  need  not  be 
sorted.  The  price  for  this  reduction  is  paid  by  V(E)  who  has  to  perform  more  computation  in 
order  to  find  the  desired  object.  The  computation  time  Is  proportional  to  n,  i.e.,  0(n).  If  the 
list  is  sorted  the  computation  time  (or  more  precisely  the  number  of  operations)  is  constant 
since  the  first  object  In  the  list  is  the  needed  one.  If,  however,  the  desired  object  has  to 
satisfy  some  function  In  addition  to  the  min  predicate,  as  for  example  in: 

cm  E-j  (i,  J:  Int)  a  E2  (k:  Int)  where  (J*k)  a  min  (i) 
the  computation  time  in  the  worst  case  can  be  proportional  to  n,  I.e.,  0(n).  Note  that 
inserting  a  new  object  into  an  event  list  requires  an  update  of  each  index.  The  6m 
complexity  of  this  update  is  O(log  n)  for  each  index,  if  the  index  has  a  tree  structure  and 
the  list  contains  n  objects. 

A  totally  different  reason  for  sorting  an  event  list  arises  In  case  of  an  event 
class  identifier  of  a  non_recurrent  type.  In  this  case,  before  Inserting  an  event  abject  Into 
the  Hst,  the  ECM  has  to  verify  that  no  Identical  element  already  exists  In  the  list.  The 
event  list  can  be  ssrted  (by  containing  an  index  when  necessary)  according  to  the  event 
par»mstsra.  The  time  complexity  of  the  search  can  be  reduced  from  0(n)  to  0(log  n)  if  the 
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!iet  (or  the  index)  has  a  tree  structure  and  the  list  contains  n  objects. 

7.12.2  Preventing  Re-evaluation  of  Expressions 

The  optimizations  described  eartier  which  prevent  revisiting  an  event  collection 
reduce  significantly  the  amount  of  expression  re-evaluation  performed  by  an  EHM.  However, 
there  are  more  cases  in  which  optimization  can  be  done.  If  the  boolean  expression  in  a 
where  clause  contains  a  subexpression  which  is  a  function  of  the  formal  parameters  of  one 
event  descriptor  (with  corresponding  event  list  k),  this  function  can  be  evaluated  once  and 
stored  as  a  hidden  parameter  of  the  event  (this  is  a  memoizing  technique).  The  saving  in 
computation  time  increases  with  the  number  of  event  descriptors  in  the  event  descriptor 
list,  since  the  number  of  event  collections  for  which  the  same  value  of  the  subexpression  is 
needed  increases.  Let  N|  be  the  number  of  existing  events  in  the  part  of  event  list  i  to  be 
searched  by  an  EHM.  The  number  of  times  the  subexpression  has  to  be  evaluated  can  reach 

max  (  FI  N|,  l)  if  the  proponed  optimization  is  not  employed. 

Wk 

There  is  a  time  space  tradeoff  here.  In  our  virtual  system,  the  decision  whether 
to  apply  this  optimization  is  easy  since  memory  Is  unbounded.  On  more  constrained  systems, 
the  compiler  must  be  given  some  information  about  the  use  of  this  optimization.  There  may 
be  several  degrees  of  this  optimization.  In  the  first  one,  it  is  not  employed  at  all.  In  the 
second  one,  it  is  employed  only  for  subexpressions  of  a  boolean  type  (which  waste  vary 
little  storage).  In  the  third  one,  the  optimization  is  used  wherever  possible. 

There  may  be  several  strategies  regarding  the  evaluation  time  of  the  hidden 
parameters  of  an  event  The  simplest  one  is  to  evaluate  when  the  event  is  caused.  The 
drawback  of  this  strategy  Is  that  If  the  event  contains  several  hidden  parameters  for  use 
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by  several  EHM'a,  It  may  be  that  some  of  them  will  not  be  needed  and  computation  time  is 
wasted.  A  slightly  complicated  algorithm  la  to  evaluate  a  hidden  parameter  the  first  time  it 
is  needed.  This  requires  in  general  both  storage  to  mark  whether  the  parameter  Is  already 
computed,  and  time  for  checking  if  it  is  already  computed.  These  tradeoffs  are  reminiscent 
of  those  related  to  the  various  mechanisms  for  passing  parameters  to  procedures;  e.g.,  call 
by  reference,  call  by  name,  call  by  value,  or  call  by  need. 

'  V 

7.12.3  Event  Class  as  a  Counter 

In  case  of  an  event  class  Identifier  having  no  (explicit  or  implicit)  parameters 
associated  with  it,  the  event  list  can  be  replaced  by  a  counter  counting  the  number  of 
existing  events  from  that  class.  The  counter  can  only  be  incremented  in  case  of  a 
multi_use  recurrent  event,  and  can  also  be  decremented  in  case  of  a  single_use 
recurrent  event.  Accesses  to  the  counter  must  be  appropriately  synchronized  and  this 
task  can  be  achieved  by  the  ECM.  The  space  required  to  represent  a  list  of  n  objects  is 
constant  (assuming  overflow  never  occurs)  as  opposed  to  0(n)  in  the  general  implementation 
of  an  event  list. 

Suppose  an  event  class  Identifier  has  parameters  associated  with  it,  and  it  does 
not  appear  as  an  argument  in  any  of  the  predicates  first,  last,  min,  or  max.  If  the  total 
number  of  distinct  parameter  combinations  that  events  from  that  class  may  assume  is 

,  bounded  by  a  small  number  k  (such  as  in  the  case  of  the  type  event  (bool,  bool)  for  which 

k*4),  the  event  list  can  be  replaced  by  k  counters,  each  corresponding  to  a  specific 

t 

parameter  combination.  The  space  required  to  represent  a  list  of  n  objects  Is  a  constant 
'  0(k)  as  apposed  to  0(n)  in  the  general  Impleeientation  of  an  event  list. 

i  . 
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in  all  the  above  cases,  If  the  event  class  Identifier  is  of  a  non_recurrent  type, 
each  of  the  counters  can  be  replaced  by  a  single  bit. 

7.12.4  Event  Class  as  a  Record  Variable 

The  problem  of  determining  at  compile  time  whether  an  event  class  can  be 
represented  as  a  record  variable  is  an  Interesting  one  since  such  a  knowledge  can  simplify 
the  corresponding  ECM.  For  an  event  class  Identifier  of  a  single_use  type  it  means  to 
decide  whether  at  any  point  in  time  at  most  one  event  object  from  that  class  exists. 
Unfortunately,  since  our  language  is  universal,  as  can  be  seen  from  chapter  6,  the  above 
problem  is  equivalent  to  the  halting  problem. 

In  case  of  an  event  class  identifier  of  a  multi_use  type,  a  similar  decision 
problem  exists.  Since  the  semantics  of  multi-use  events  is  that  they  are  never  forgotten, 
ft  seems  that  the  prospects  for  optimization  In  this  case  are  even  fewer  than  in  the  previous 
case.  However,  there  are  cases  which  can  be  easily  detected  by  the  compiler  In  which  an 
event  class  can  be  represented  as  a  record  variable. 

One  such  case  Is  that  of  an  event  class  identifier  E  of  a  mutti_use  recurrent 
type  such  that  the  where  clause  of  every  event  handler  H  containing  it  in  Its  event 
descriptor  list  satisfies  the  following  conditions: 

1 .  No  formal  (explicit  or  implicit)  parameter  of  the  event  descriptor  associated  with 

E  appears  In  the  boolean  expression  of  the  where  clause.. 

2.  E  appears  In  exactly  one  event  descriptor  of  H. 

3.  One  of  the  following  conditions  holds: 

a.  In  every  H,  E  appears  as  an  argument  of  exactly  one  predicate  first. 
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and  no  formal  parameter  of  E  appears  in  the  argument  of  any  other 
predicate. 

b.  In  every  H,  E  appears  as  an  argument  of  exactly  one  predicate  last, 
and  no  formal  parameter  of  E  appears  In  the  argument  of  any  other 
predicate. 

The  common  characteristic  of  all  the  above  cases  Is  that  the  ECM  must  remember 
only  one  event  object.  The  event  object  has  some  minimum  (maximum)  value  associated  with 
It:  the  Index  of  the  event  object  in  the  event  list  (which  is  not  needed).  In  case  a,  only  the 
first  occurred  event  is  remembered;  in  case  b,  only  the  last  event  which  occurred  so  far  is 
remembered. 

Event  objects  which  are  no  longer  needed  by  the  ECM  cannot  be  simply  garbage 
collected  since  references  to  them  may  exist  in  various  instances  of  event  handlers.  A 
slight  modification  of  the  reference  count  mechanism  (In  which  references  within  instances 
of  event  handlers  are  counted  in  addition  to  references  within  EHM's)  can  be  used  together 
with  the  state  of  a  list  element  to  appropriately  solve  the  garbage  collection  problem  in 
these  cases. 

7.12.6  Event  Class  as  an  Array  of  Records 

The  optimization  discussed  In  the  previous  section  can  be  extended  to  deal  with 
an  array  of  records  if  condition  1  Is  relaxed  to  the  following  one: 

1 '.  Only  formal  parameters  from  a  subset  S  of  the  set  of  formal  parameters  of  E  are 

used  in  ..  ^olean  expressions  In  where  clauses  of  all  H. 

In  this  case,  the  parameters  identified  by  S  can  serve  as  array  Indexes.  The  array  can  be 
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implemented  as  a  sparse  array  since  In  general,  not  ail  Its  elements  exist. 

This  optimization  captures,  among  the  others,  uses  of  multi-use  events  for 
database  applications  as  shown  In  the  readers  writers  example  In  chapter  6. 

7.12.6  Combined  EHM's 

A  combined  EHM  can  be  associated  with  n>1  event  handlers  H1 ,  ...  ,  Hn  containing 
identical  event  descriptor  lists  (except  possibly  different  formal  parameters),  instead  of  n 
separate  EHM's.  The  advantages  of  this  approach  are  several:  Less  computational 
resources  are  needed,  less  messages  are  exchanged  with  the  relevant  ECM's,  and  the  load 
on  each  of  these  ECM's  is  reduced  since  they  have  to  handle  fewer  requests.  Each  of  the 
above  reductions  can  reach  a  factor  of  n  (e.g.,  when  the  n  event  handlers  are  identical). 
One  event  space  can  be  associated  with  the  n  event  handlers;  the  combined  EHM  can  cover 
It,  find  event  collections  matching  one  or  more  of  the  event  handler  headings,  and  activate 
Instances  of  those  event  handlers  according  to  our  previous  schemes. 

If  the  event  handlers  are  single_use  event  handlers,  then  once  an  event 
collection  which  matches  one  of  them  H|  is  found,  there  is  no  need  to  check  whether  it 
matches  the  others.  The  reason  Is  that  after  the  acquisition  algorithm  is  applied  and 
terminates  (successfully  or  unsuccessfully)  the  event  collection  no  longer  exists.  If 
however,  the  event  handlers  are  multi_use  event  handlers,  checking  the  other  event 
handlers  Is  In  general  needed.  The  exceptions  are  those  EHM's  for  which  it  has  been 
established  that  the  boolean  expressions  in  their  where  clauses  and  the  boolean  expression 
of  H|  are  not  mutually  aatlsfiable. 
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As  was  indicated  earlier,  the  problem  whether  two  general  boolean  expressions, 
whose  terms  contain  relations  between  integer  expressions  (containing  the  operators  +,  -, 
*,  and  /),  are  mutually  satisfiable  is  undecidable.  For  simple  boolean  expressions  in  which 
the  relations  are  restricted  to  atoms  of  the  form: 

<identifier>  <relational__operator>  <constant> 

(for  <relational_operator>  as  defined  earlier  in  this  chapter)  the  problem  becomes  decidable 
but  NP-hard.  Polynomial  algorithms  for  more  restricted  cases,  e.g.,  conjunction  of  atoms  are 
known  [Wo-77].  In  such  cases,  the  compiler  can  generate  more  efficient  combined  EHM's. 

An  example  of  a  situation  in  which  the  conditions  for  creating  a  combined  EHM  are 
met  is  the  equivalent  of  a  case  statement  (or  an  if  statement).  In  the  general  scheme 
described  in  previous  sections,  the  conditions  triggering  each  branch  of  a  case  statement 
are  evaluated  concurrently  whereas  here  they  are  evaluated  serially.  This  is  the  price  paid 
for  allocating  fewer  computational  resources  for  this  task. 

7.12.7  Eliminating  Redundant  Events  and  Event  Handlers 

The  first  kind  of  redundant  events  are  those  which  probably  stem  from 
programming  errors.  In  one  simple  case,  event  class  Identifiers  which  do  not  appear  in  any 
event  handler  heading  can  be  eliminated  from  the  program  (unless  they  are  system  event 
class  identifiers)  without  changing  the  meaning  of  the  program.  The  only  changes  in  the 
program  behavior  are  those  related  to  execution  times,  over  which  the  programmer  has  no 
direct  control  anyhow.  In  another  simple  case,  an  event  handler  containing  In  its  event 
descriptor  list  at  least  one  event  class  Identifier  whose  events  can  never  occur,  can  be 
eliminated.  In  a  more  general  case,  there  is  a  group  of  event  handlers  Hj . Hn  each 
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containing  In  its  event  descriptor  list  at  least  one  event  class  identifier  from  the  set 

E^ . Em  whose  events  can  be  caused  only  in  H-p  ...  ,  Hn.  In  this  case,  all  event  handlers 

H-j . Hn  can  be  eliminated  from  the  program  without  changing  Its  behavior.  We  shall  not 

pursue  this  kind  of  optimization  since  detecting  such  cases  will  normally  cause  the 
programmer  to  modify  his  program  and  recompile  it. 

A  more  interesting  problem  is  that  of  detecting  and  eliminating  intermediate 
events.  This  case  is  important  since  It  occurs  when  a  program  is  developed  in  a  top  down 
approach  without  deleting  the  intermediate  steps  (as  discussed  in  chapter  3).  The  simplest 
case  is  that  of  an  event  class  identifier  E  which  appears  in  the  event  descriptor  list  of  one 
event  handler  H;  H  contains  only  one  event  descriptor  in  its  heading  and  has  no  where 
clause.  In  this  case,  E  can  be  eliminated  from  the  program.  The  script  of  H  is  appropriately 
substituted  Into  every  event  handler  where  events  from  class  E  are  caused.  This 
substitution  raises  several  problems  which  can  be  easily  dealt  with  by  the  compiler,  such  as 
determining  scopes  of  identifiers.  Such  a  substitution  may  yield  a  script  which  defines  a 
serial  /  parallel  combination  on  its  events  (rather  than  the  more  restricted  case  of  either  a 
serial  or  a  parallel  order  as  allowed  in  EBL).  Implementing  these  extended  scripts  should  not 
pose  serious  problems. 

In  a  slightly  more  general  case,  E  appears  in  several  event  handlers  H-j,  ...  ,  Hn 
each  restricted  as  H  above  but  a  where  clause  without  predicates  is  allowed  in  each  H|.  A 
slightly  more  complicated  substitution  is  needed  here.  It  requires  some  kind  of  an  if 
statement  or  a  case  statement  within  a  script,  and  these  can  be  easily  implemented. 
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7.13  Tag  Handling  and  Tag  Optimizations 

Tag  handling  without  optimization  is  not  complicated.  A  simple  distributed  tag 
allocation  scheme  allocates  as  a  tag  value  some  combination  of  the  number  of  the  processor 
which  executes  the  instance  of  the  event  handler  which  defines  the  tag,  and  a  unique 
number  (unique  to  this  processor).  This  approach  eliminates  the  need  for  a  central  tag 
allocator.  Tag  operations  are  performed  on  those  numbers  in  the  obvious  way. 

Some  optimizations  can  be  performed  by  observing  that  the  main  (and  intended) 
use  of  tags  is  for  joining  n  concurrent  branches  of  a  computation.  The  general  form  of  such  a 
join  is: 

on  E1  (  ....  t1 :  tag,  ...  )  a  E2  (  ....  t2:  tag, ...  )  a  ...  a  En  (  ....  tn:  tag,  ...  ) 

where  B  and  tj*^  and  ...  and  tn_ ^  =tn 

or  slight  variations  of  it,  where  B  Is  a  boolean  expression  (without  predicates).  A  great 
inefficiency  can  result  in  cases  where  there  are  many  events  in  each  event  class  E|,  but 
the  same  tag  value  appears  in  few  events;  in  particular,  in  exactly  n  events.  This  is 
normally  the  case  when  joining  n  branches  of  a  computation  whose  instances  are  activated 
concurrently  many  times. 

The  feature  of  an  ECM  which  allows  specifying  a  simple  condition  in  a  next 
request  saves  communication  overhead  since  the  condition  sent  to  E|  (i>1)  can  be  tj=ot, 
where  oc  is  the  value  of  the  tag  parameter  of  E  j .  However,  each  ECM  has  to  scan  Its  event 
list  until  an  event  with  appropriate  tag  is  selected. 
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An  attractive  optimization  la  to  allocate  a  distinct  processor  each  time  a  new  tag 
value  is  needed  and  to  take  the  processor  number  to  be  part  of  the  tag  vdue.  This  tag 
processor  maintains  a  tag  list.  Each  element  of  this  list  contains  a  reference  to  an  event 
object  carrying  the  same  tag  value  and  an  Identifier  of  the  class  of  that  event  (e.g.,  the 
number  of  the  processor  on  which  the  corresponding  ECM  resides).  All  events  carrying  the 
same  tag  are  pointed  to  by  the  tag  list. 

Each  time  an  event  object  carrying  a  tag  parameter  Is  inserted  into  an  event  list, 
a  message  Is  sent  to  the  appropriate  tag  processor  by  the  ECM;  the  tag  processor  Inserts  a 
new  element  into  its  list.  Each  time  an  event  object  is  deleted,  the  corresponding  element 
in  the  tag  list  is  also  deleted.  The  tag  processor  Itself  can  be  returned  to  the  free 
processor  pool  when  Its  list  becomes  empty  and  its  tag  value  can  no  more  be  copied  as  a 
parameter  o *  newer  events  (a  state  which  should  not  be  difficult  to  detect).  This  can 
happen  only  if  no  event  object  of  a  multi_use  type  is  pointed  to  by  the  tag  list,  since 
multi_use  events  are  never  forgotten. 

The  overhead  in  finding  matching  event  collections  can  be  greatly  reduced  by 
using  the  tag  processor.  Instead  of  finding  matching  event  collections  by  scanning  event 
lists,  it  can  be  done  by  sending  messages  to  the  tag  processor.  In  the  normal  (intended) 
tag  uses,  this  approach  decreases  the  time  needed  for  finding  a  matching  event  collection. 
In  other  uses  the  time  may  Increase.  This  situation  can  be  easily  remedied  by  using  the 
original  technique  and  the  tag  processor  technique  concurrently  and  aborting  the  losing  one 
whenever  a  result  Is  obtained. 
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7.14  Summary 

A  manager  based  implementation  scheme  has  been  developed  in  this  chapter. 
This  scheme  associates  an  event  class  manager  with  each  event  class  identifier  in  the 
program,  and  an  event  handler  manager  with  each  event  handler.  These  communicating 
managers  operate  without  any  centralized  control.  A  two  phase  distributed  locking 
(acquisition)  algorithm  in  which  deadlocks  are  prevented  has  been  developed.  Many 
existing  distributed  locking  algorithms  prevent  deadlocks  by  using  a  total  order  on  all 
objects  to  be  locked.  Our  locking  algorithm  only  uses  a  partial  order  on  all  object  classes. 
The  advantage  of  this  algorithm  is  that  objects  can  be  locked  by  a  requestor  concurrently 
(and  not  sequentially  as  in  other  algorithms). 

The  previous  chapter  has  demonstrated  the  power  and  the  roles  of  some  of  EBL's 
predicates.  This  chapter  has  shown  that  predicates  somewhat  complicate  the 
implementation  of  the  language.  It  seems  that  the  complication  is  justified. 


Section  8 


180- 


Network  Implementation 


8.  Network  Implementation 

Thla  chapter  investigates  strategies  for  implementation  of  EBL  on  a  processor 
network,  in  contrast  to  the  previous  chapter,  this  chapter  does  not  assume  unlimited 
computational  resources.  The  network  consists  of  a  fixed  number  of  processors  p,  each 
equipped  with  bounded  local  storage.  For  simplicity  we  assume  that  all  processors  are 
identical.  The  network  Is  connected  but  each  processor  is  directly  connected  only  to  a 
subset  of  the  set  of  processors  in  the  network.  Its  neighbors.  An  example  of  a  network 
satisfying  the  above  conditions  Is  the  MuNet  [Wa-78b].  We  no  longer  assume  that  the 
cost  of  communication  between  program  objects  residing  on  different  processors  is  zero.  In 
fact,  this  cost  will  be  one  of  the  prime  factors  in  the  Implementation  scheme. 

We  would  like  to  use  the  strategy  outlined  in  the  previous  chapter  but  the 
limitations  of  the  network  pose  several  problems: 

1.  It  may  not  be  possible  to  allocate  a  distinct  processor  for  each  task;  several 
tasks  may  have  to  share  a  single  processor. 

2.  An  object  (e.g.,  an  event  list)  may  not  fit  into  the  memory  of  one  processor  and 
may  spread  over  several  processors. 

3.  Objects  may  have  to  move  from  one  processor  to  another  due  to  memory 
limitation  in  order  to  evenly  share  load  among  processors,  or  in  order  to  decrease 


communication  overhead. 


Object  Management 


181  - 


Section  8.1 


8.1  Object  Management 

This  section  discusses  the  issues  of  object  management  and  communication 
among  objects  in  a  network.  The  main  kinds  of  objects  in  our  scheme  are:  managers  (ECM's 
and  EHM's),  event  objects  (which  are  kept  within  event  lists  managed  by  ECM's),  scripts  of 
event  handlers  (a  copy  of  an  event  handler  script  may  exist  in  more  than  one  processor  in 
the  network),  temporary  tasks  (instances  of  event  handlers,  or  short  tasks  spawned  by 
managers  or  by  instances  of  event  handlers),  and  messages  exchanged  among  the  above 
objects.  An  important  issue  in  a  network  implementation,  in  contrast  to  the  virtual  system 
Implementation  of  the  previous  chapter,  is  on  which  processor  in  a  network  an  object 
resides.  The  Issue  Is  important  due  to  its  major  effect  on  performance.  A  great  deal  of  this 
chapter  (sections  8.2-8.7)  investigates  the  issue  of  finding  good  initial  object  distributions. 

It  Is  important  to  understand  that  once  all  managers  are  successfully  allocated  to 
processors  (which  must  be  done  initially)  there  is  never  a  necessity  of  moving  a  manager.  If 
due  to  memory  limitation  something  must  be  moved  from  one  proc-  ssor  then  temporary  tasks, 
scripts  of  event  handlers,  and  parts  of  event  lists  can  be  moved;  the  managers  need  not 
move.  Moving  a  manager  is  only  a  matter  of  efficiency.  The  only  reason  for  moving  a 
manager  is  decreasing  communication  overhead.  An  ECM  may  move  to  processor  Pu  if  most 
of  Its  event  list  elements  reside  on  Pu.  An  EHM  M(H)  communicating  with  several  ECM's 
M(E-|),  ...  ,  M(En)  may  move  to  (or  close  to)  P(M(E())  if  the  event  list  associated  with  Ej 
contains  the  largest  number  of  events  to  be  checked  by  M(H)  over  E1 . En. 

Since  objects  may  rove  among  processors,  the  question  of  how  they  should  be 
addressed  arises.  Our  previous  solution  In  which  the  address  contains  the  processor  number 
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may  not  bo  efficient  since  each  time  the  object  moves  references  to  It  must  be  updated.  In 
a  more  appropriate  addressing  scheme  an  object  Is  referenced  by  using  Its  name  (a  logical 
address).  Some  mechanism  Is  needed  for  translating  an  object  name  to  a  physical  (network) 
address.  Such  a  translation  can  be  achieved  by  keeping  in  each  node  a  translation  table.  An 
entry  In  such  a  table  can  specify,  for  example,  for  each  object  name  a  processor  number 
and  an  address  local  to  that  processor  (or  one  of  these  two  items  and  an  indication  whether 
the  object  is  local  or  remote).  This  scheme  is  still  not  flexible  enough  (considering  object 
movement)  and  suffers  from  a  high  space  overhead. 

For  concreteness  we  will  select  a  particular  translation  mechanism,  although  most 
of  the  discussions  in  this  chapter  are  independent  of  this  mechanism.  For  each  object  0|  a 
tree  is  created  ( reference  tree)  spanning  all  network  nodes  containing  objects  which 
reference  0(  (as  well  as  other  nodes  as  needed  for  achieving  a  connected  tree).  This 
mechanism  has  been  developed  in  [Ha-78,  Ha-79].  Only  a  subset  of  the  features  of 
reference  trees  described  there  are  needed  in  our  implementation;  however,  the  same  name 
will  be  used  here.  In  our  case,  a  reference  tree  for  object  0(  is  a  rooted  tree;  the  root  is 
the  node  on  which  0|  resides.  A  principal  advantage  of  reference  trees  Is  that  if  0|  moves, 
only  the  part  of  the  tree  to  which  0|  is  connected  need  be  updated,  and  not  the  whole  tree. 
[Ha-78]  describes  a  distributed  algorithm  for  maintaining  reference  trees;  a  processor 
manipulates  a  reference  tree  only  on  the  basis  of  interactions  with  its  Immediate  neighbors 
in  the  network. 

Other  advantages  are  obtained  if  reference  trees  are  used.  Not  all  nodes  in  the 
network  participate  In  each  tree  (i.e.,  not  every  node  knows  the  names  of  all  objects); 
therefore,  space  overhead  can  be  smaller  than  in  the  case  of  translation  tables  (discussed 
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earlier).  Each  node  does  not  know  the  complete  route  to  the  root  of  the  tree,  but  rather, 
only  the  next  link  to  use  (like  in  the  Arpanet  routing  algorithm);  this  adds  to  the  flexibility  of 
the  scheme.  Routing  of  messages  from  a  node  on  a  tree  to  the  root  is  trivial.  The  tree  can 
also  be  used  for  communication  of  messages  from  the  root  to  the  rest  of  the  tree  as 
discussed  next. 

An  interesting  question  Is:  in  what  ways  can  a  broadcast  from  one  manager  to 
several  others  be  implemented?  The  need  arises  when  an  ECM  M  wishes  to  broadcast  the 
occurrence  of  some  change  in  its  event  list  to  several  EHM's.  Similarly  an  EHM  M  may  wish 
to  broadcast  to  several  ECM's  a  request  such  as  "read  boundary".  One  approach  is  that  M 
sends  separate  messages,  one  for  each  destined  manager  along  that  manager's  tree.  The 
second  approach  is  to  broadcast  the  message  on  M's  own  tree  from  the  root  to  the  leaves. 
In  every  node  to  which  the  message  arrives  a  check  is  made  whether  any  manager  is 
interested  in  the  message.  The  message  is  passed  on  towards  the  leaves  if  there  are  more 
managers  in  that  direction.  Note  that  both  approaches  are  possible  since  in  our 
implementation  scheme  if  manager  Mj  communicates  with  manager  Mj  then  P(M|)  is  included 
in  the  tree  of  Mj  and  P(Mj)  is  included  in  the  tree  of  Mj. 

The  selection  of  the  broadcast  strategy  can  be  dynamically  made  by  M,  based  on 
information  that  it  gathers.  If  M  has  to  send  messages  to  m  managers  Mjt  ...  ,  Mm  and  the 
distance  between  M  and  M|  along  Mj's  reference  tree  Is  Dj  (assuming  a  distance  1  between 
neighboring  processors)  then  the  communication  coat  In  the  first  approach  Is:  Cj  *  Y.  Dj.  In 
the  second  approach  the  communication  cost  C2  is  at  most  n-1  where  n  is  the  total  number 
of  nodes  in  M's  reference  tree.  Keeping  track  of  and  C2  is  quite  simple.  Cg,  for 
example,  can  be  calculated  by  a  dtatributed  algorithm  which  propagates  the  appropriate 
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Information  from  the  leaves  towards  the  root  of  M's  tree  whenever  changes  in  the  structure 
of  the  tree  occur.  Since  managers  do  not  move  frequently,  the  overhead  involved  in 
calculating  and  C2  Is  expected  to  be  low. 

One  approach  could  be  to  associate  a  reference  tree  with  each  object  in  the 
system.  This  approach  may  work  but  It  totally  Ignores  the  special  properties  of  the 
language.  The  advance  knowledge  of  the  kinds  of  objects  dealt  with  and  their  relationships 
with  each  other  can  be  used  to  decrease  the  number  of  needed  trees  by  combining  several 
trees  into  one  (thus  decreasing  space  and  time  overheads).  In  particular,  there  is  no  need 
to  create  a  distinct  tree  for  each  event  object.  One  reference  tree  can  be  associated  with 
the  corresponding  ECM,  and  the  ECM  can  maintain  its  objects  independently  of  the 
reference  tree  by  some  less  expensive  mechanism.  The  problem  of  a  list  which  does  not  fit 
into  one  processor  can  be  dealt  with  by  spreading  the  list  among  several  processors  and 
allocating  secondary  ECM's  to  these  processors,  controlled  by  the  (main)  ECM.  A  separate 
reference  tree  can  join  the  secondary  ECM's  with  the  main  ECM. 

An  ECM  is  a  heavy  object  since  In  general  moving  it  involves  moving  many  objects 
(event  objects).  Moving  a  manager  requires  updating  several  manager  trees;  the  tree 
associated  with  that  manager,  and  those  associated  with  the  managers  with  which  it 
communicates;  as  welt  as  trees  associated  with  temporary  tasks.  Thus,  in  our  scheme 
managers  will  not  move  frequently,  but  rather,  temporary  tasks  will  be  those  which  normally 
move. 


Sections  8.2-8.7  investigate  the  problem  of  initial  distribution  of  objects  in  a 


network.  Section  8.8-8.0  Investigate  the  problem  of  creating  Initial  reference  trees. 
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8.2  Initial  Object  Distribution 

We  could  stop  at  this  point  and  say  that  after  a  program  is  compiled  the  loader 
loads  the  objects  generated  by  the  compiler  to  one  or  more  processors  in  the  network 
regardless  of  their  relationships  with  each  other;  during  the  course  of  the  program 
execution  objects  will  move  in  such  a  way  that  overhead  is  minimized  and  load  is  equally 
distributed.  However,  the  transient  period  may  last  over  most  (or  even  all)  of  the  program 
execution  time.  This  is  true  in  particular  for  programs  whose  run  time  is  short. 

Thus  the  problem  of  finding  a  good  (or  optimal)  initial  object  distribution  in  the 
network  according  to  some  goodness  criterion  (which  is  discussed  in  section  8.3)  is  of  great 
importance.  Before  a  program  is  loaded,  a  global  analysis  can  be  made,  based  on  data 
generated  by  the  compiler  and  the  current  structure  of  the  network,  whose  purpose  is  to 
find  a  good  initial  object  distribution  and  the  corresponding  reference  trees. 

Problems  similar  to  ours  have  been  discussed  In  the  literature.  We  shortly 
discuss  some  of  them  and  explain  why  their  results  are  not  adequate  for  our  purpose. 
[St-78a]  discusses  the  problem  of  distributing  program  modules  In  a  distributed  system.  As 
examples  of  distributed  systems  the  paper  gives:  the  Arpanet,  C.mmp,  Cm*,  Pluribus,  and  a 
dual  processor  system.  The  program  modules  are  assigned  to  processors  In  a  way  that 
minimizes  a  cost  function  Z.  Z  consists  of  the  sum  of  communication  costs  for  all  pairs  of 
communicating  modules  residing  on  different  processors  and  the  sum  of  execution  cost  for 
each  program  module  at  the  processor  on  which  it  resides. 


Section  8.2 


-  186 


Initial  Object  Distribution 


The  paper  implicitly  assumes  that  the  distance  (or  the  delay)  between  every  pair 
of  processors  in  the  system  is  identical  (e.g.,  a  fully  connected  network);  this  assumption  is 
not  correct  for  most  of  the  above  systems,  and  not  In  our  case.  The  cost  function  does  not 
make  sense  if  the  processors  are  identical  since  in  such  case  its  minimum  is  obtained  by 
allocating  all  the  program  modules  to  one  processor,  ignoring  the  rest  of  the  available 
resources,  and  that  is  not  the  paper's  intent.  In  most  of  the  above  systems  however,  the 
processors  are  Identical.  The  paper  primarily  deals  with  two  and  three  processor  systems, 
thus,  the  results  are  not  applicable  to  our  case. 

[Je-77]  deals  with  a  similar  problem  but  does  not  take  into  account  storage  cost, 
and  as  [St- 78a]  implicitly  assumes  equal  distances  between  every  pair  of  processors  in  the 
network.  The  method  of  finding  the  optimal  distribution  is  simila.  to  that  of  [St-78a],  finding 
cut  sets  in  a  weighted  graph  (the  arcs  are  weighted)  yielding  a  minimum  total  weight.  The 
underlying  model  does  not  capture  the  problems  we  try  to  solve,  therefore  the  results  are 
not  applicable  to  our  case. 

[Mo-77]  deals  with  optimal  distribution  of  programs  and  files  in  a  network.  The 
cost  function  consists  of  communication  cost  terms  and  storage  cost  terms.  The  paper 
assumes  that  program  storage  cost  is  negligible  in  comparison  to  file  storage  cost  and 
solves  the  problem  by  decomposing  It  to  Individual  file  minimization  problems.  (The 
justification  of  the  decomposition  is  given  In  another  paper.) 

The  results  cannot  be  used  for  our  case  due  to  several  reasons.  First,  In  our  case 
the  problem  cannot  be  decomposed  analogously  to  their  case.  Second,  their  storage  cost  Is 
simply  the  sum  of  the  storage  cost  of  each  file  in  the  node  on  which  It  resides.  If  we  use 
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such  a  simple  storage  cost  function  in  our  case,  then  the  storage  cost  function  is  constant 
for  a  given  program  since  all  processors  are  Identical.  Assigning  ail  objects  to  a  single 
processor  will  always  result  in  minimum  communication  cost,  and  therefore  in  minimum  total 
cost.  Such  a  degenerate  fixed  solution  is  not  acceptable  in  our  case  since  it  does  not 
exploit  available  computational  resources. 

8.3  The  Cost  Function 

The  distribution  problem  is  carefully  analyzed  in  the  following  sections.  The 
results  are  not  limited  to  the  context  of  EBL  therefore  the  discussion  proceeds  in  more 
general  terms;  the  corresponding  terms  of  EBL  or  our  implementation  scheme  are  given  when 
necessary.  We  first  define  several  concepts  which  are  used  in  the  sequel. 

The  processor  graph  PG  (N,  A)  is  an  undirected  connected  simple  graph 
representing  the  processor  network.  Each  of  the  p  processors  is  represented  by  a  node  in 
N,  and  each  link  is  represented  by  an  arc  in  A.  A  distance  1  is  associated  with  each  arc 
(assuming  a  constant  delay  between  any  directly  connected  processors).  From  the 
processor  graph  the  distance  matrix  D  can  be  constructed.  The  element  Duv  of  D 
represents  the  shortest  path  distance  between  nodes  Py  and  Pv  in  PG.  Note  that  D  is 
symmetric  and  Duu=0  for  all  u.  D  can  be  constructed  In  polynomial  time;  an  0(p3)  algorithm 
which  also  produces  the  shortest  paths  (not  only  their  lengths)  Is  described  in  [Re-77b]. 

The  communication  graph  CG  (N\  A *)  is  an  undirected  (not  necessarily 
connected)  simple  graph  having  n  nodes  representing  the  objects  In  the  system  and  their 
interactions.  A  non-negative  Integer  cost  is  associated  with  each  arc  in  A',  and  a 
non-negative  integer  weight  W(  Is  associated  with  each  node  In  N'.  The  arcs  costs  can  be 
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represented  by  a  symmetric  cost  matrix  C.  The  element  Cjj  of  C  is  the  cost  associated  with 
the  arc  connecting  nodes  i  and  J.  If  there  is  no  arc  connecting  nodes  t  and  j  then  Cjj=0; 
Cjj=0  for  all  i  since  CG  is  a  simple  graph. 

For  each  EBL  program  a  communication  graph  can  be  created.  The  nodes  are 
corresponding  to  the  program  objects  whom  we  wish  to  distribute  in  the  network  (ECM's, 
EHM's,  and  scripts  of  event  handlers).  An  arc  between  nodes  i  and  j  indicates  that  objects 
i  and  j  communicate  with  each  other.  Cy  represents  the  communication  cost  per  unit 
distance  between  objects  i  and  j.  Wj  Is  the  weight  associated  with  object  i;  it  may,  for 
example,  represent  its  storage  requirement,  its  CPU  requirement,  or  any  combination  of 
these  two  factors. 

In  the  sequel,  the  following  notation  is  used:  n  represents  the  number  of  nodes  in 
CG;  p  represents  the  number  of  nodes  in  PG;  i,  j  are  nodes  in  CG;  Pu,  Py  are  nodes  in  PG 
(however,  they  may  also  denote  the  corresponding  processors  in  the  processor  network); 
P(i)  is  the  node  in  PG  to  which  object  I  is  assigned  (or  the  corresponding  processor). 

Our  goodness  criterion  for  a  specific  distribution  will  be  the  value  of  a  cost 

function  Z  which  we  try  to  minimize.  Z  consists  of  two  parts:  Zc  the  communication  cost,  and 

Z |  the  processor  load  cost;  Z=ZC+Z|.  We  assume  that  Zc  has  the  following  form: 

Zc  •  (1/2)  Z  ci]Dp(|)p(j) 

U 

Note  that  if  objects  I  and  j  are  assigned  to  the  same  node  In  PG  the  contribution  of  their 

communication  to  Zc  is  always  zero.  The  processor  load  cost  Z(  is  the  sum  of  the  individual 

processor  load  cost  Z(p  over  all  nodes  in  PG;  i.e.,  Zj  =  Z  Z)p.  There  are  many  reasonable 

pu 

ways  to  select  Z|p.  We  shall  not  select  a  specific  function;  Instead  we  assume  that  it 
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satisfies  the  following  conditions: 

1 .  weight:  Zi_  is  a  function  of  H  Wu  where  i  ranges  over  the  objects  assigned  to 

I 

the  particular  node  of  PG. 

2.  integrity:  Z(p(X)  Is  defined  for  every  non-negative  integer,  and  assumes  oniy 
non-negative  integer  values. 

3.  threshold:  Z|p(X)=0  for  every  non-negative  integer  X<Wy.  The  non-negative 
integer  Wy  is  the  threshold  of  the  function. 

4.  monotonicity:  Z|p(X+1)  >  Z|p(X)  for  every  integer  X>Wy.  This  reflects  that 
increasing  the  total  weight  on  a  processor  (above  the  threshold)  implies  an 
increase  In  that  processor's  load  cost. 

6.  concavity:  Z)p(X)  +  Z(p(X+2)  >  2Z|p(X+1)  for  every  integer  X>Wy+1.  This 
guarantees  that  if  the  total  weight  at  Pu  is  heigher  than  the  total  weight  at  Pv, 
moving  an  object  from  node  Pu  to  node  Pv  does  not  increase  the  total  processor 
load  cost  Z|. 

6.  polynomial:  Z|p(X)  can  be  computed  in  deterministic  polynomial  time  in  the  length 
of  X. 


Some  examples  of  Z)p  are: 

(1)  Z|p(X)* 

0 

M+X-Wy 

X  X 

V  IA 

(2)  Zjp(X)  = 

1  o 

l  (X-Wy)M 

X<Wy 

X>Wy 

(3)  Z|p(X)  = 

f  0 

l  (X-Wy)2 

X<Wy 

X>Wy 

where  Wy  is  a  noii-negative  integer  and  M  la  a  positive  integer.  In  the  sequel,  a  cost 
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function  means  a  specific  cost  function  satisfying  the  previous  concHtione.  The  cost  function 
may  have  several  parameters:  Wj  is  one  parameter;  M  is  an  exempte  of  another  one.  Note 
that  the  evaluation  of  Z  for  a  given  object  distribution  can  be  done  by  a  deterministic 
polynomial  algorithm. 

8.4  The  Object  Distribution  Problem 

In  terms  of  the  previously  defined  graphs,  an  object  distribution  is  the 
association  of  each  node  of  a  given  CG  with  exactly  one  node  of  a  given  PG.  The  problem 
we  are  trying  to  solve  is  the  following. 

The  Distribution  Problem: 

Given  a  CG,  a  PG,  a  cost  function,  and  the  cost  function  parameters;  determine  the  object 
distribution  with  minimum  cost  (the  optimal  distribution )  Zm .  A  closely  related  problem  Is  the 
following. 

The  Distribution  Decision  Problem: 

Given  a  CG,  a  PG,  a  cost  function,  the  cost  function  parameters,  and  a  positive  integer  b; 
determine  whether  there  exists  an  object  distribution  of  cost  at  most  b. 

In  practice,  the  object  distribution  may  have  to  satisfy  some  constraints.  An 
example  of  such  a  constraint  Is  an  object  which  must  be  assigned  to  a  specific  node  of  the 
PG;  e.g.,  an  ECM  corresponding  to  a  system  event  class  identifier  associated  with  some  I/O 
device.  Handling  such  constraints  should  not  be  difficult  and  we  shal  not  treat  them  In  the 


sequel. 


/  AD-A081  950 
UNCLASSIFIED 

?.'4  I 


MASSACHUSETTS  INST  OF  TECH  CAMBRIDGE  LAB  FOR  COMPUTE— ETC  F/8  9/2 
THE  EVENT  BASED  LANGUA6E  AND  ITS  MULTIPLE  PROCESSOR  IMPLENENTAT— ETC (U> 
JAN  80  A  REUVEN!  N00014-75-C-0661 

MIT/LCS/TR-226  NL 


MICROCOPY  RtSOlUIION  UST  CHART 

NAIIONAI  Hllfff  Air  iif  SIANPAKfK  !•»».;  A 


u 


•  ^ 

l* 

I 

I 


r  ■ 


.Xie*** 


**..  V 

tim 


K? 


The  Object  Distribution  Problem  -  101  -  Section  8.4 

Let  us  Informally  introduce  several  concepts  which  are  used  In  this  chapter; 
formal  definitions  can  be  found  In  [Ga-79].  NP  is  the  class  of  all  decision  problems  that  can 
be  solved  by  polynomial  time  non  deterministic  algorithms.  A  decision  problem  P  is 
MP-complete  If  it  is  In  NP,  and  all  other  problems  In  NP  are  polynomially  transformable  to  P. 
A  problem  P  is  WP-hard  if  there  exists  some  WP-complete  problem  that  is  polynomially 
transformable  to  P.  An  A/P-hard  problem  Is  at  least  as  hard  as  any  problem  In  NP. 

Theorem  1 

The  distribution  decision  problem  Is  NP- complete. 

Proof:  We  first  show  that  the  Hamiltonian  circuit  problem  (Does  a  p  node  undirected  graph  G 
have  a  Hamiltonian  circuit?)  is  polynomially  transformable  to  the  distribution  decision 
problem.  We  construct  a  PG  G1  by  converting  G  to  a  graph  satisfying  the  requirements  of  a 
PG.  First,  all  parallel  arcs  but  one  connecting  any  two  nodes,  and  all  self  loops  are 
eliminated.  Second,  if  G  consists  of  q  connected  components  then  q-1  arcs  are  added  to 
convert  it  to  a  connected  graph.  Note  that  G*  has  a  Hamiltonian  circuit  iff  G  has  a 
Hamiltonian  circuit.  As  a  CG  we  construct  a  ring  of  p  nodes  and  p  arcs.  Each  arc  has  a  cost 
1  associated  with  it,  and  each  node  has  a  weight  W  associated  with  it.  W  and  the  cost 
function  parameters  are  selected  in  a  way  that  guarantees  that  Z  is  minimized  by  an  object 
distribution  which  associates  exactly  one  node  of  the  CG  with  each  node  of  the  PG.  This 
can  be  easily  done  since  Zc<p2.  In  particular,  we  choose  W«Wy*p2.  Our  transformation  is 
clearly  a  polynomial  transformation.  In  the  optimal  distribution,  each  node  of  the  PG  has  a 
total  weight  W  associated  with  it  thus  Z(  can  be  calculated;  we  get  Z(*0,  therefore  Z^-Z,.. 

It  Is  clear  that  Zm*p  iff  G1  has  a  Hamiltonian  circuit,  i.e.,  iff  G  has  a  Hamiltonian 

circuit. 
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To  show  that  tha  problem  la  In  NP  wa  uaa  tha  foMowktg  algorithm  which  first  chooaoa  an 
objact  distribution: 

for  l»1  to  n  do  *0(n) 

X|  *  cholea  ({1, ... ,  p>) 

and 

if  Z(x^  l..,xn,ClD)^b  -Polynomial 

than  suecass 
alsa  failura 

whara  the  meaning  of  the  primitives  choice,  success,  and  failura  is  as  defined  In  [Re-77b]. 
Since  tha  above  algorithm  is  clearly  a  nondetermlnistic  polynomially  bounded  algorithm,  tha 
problem  is  In  NP.  This  completes  the  proof  of  the  theorem. 

Corollary  1.1 

The  distribution  problem  is  iVP-hard. 

We  shall  continue  the  analysis  of  the  distribution  problem  In  section  8.0.  We  now  suggest 
several  related  interesting  problems. 

8.5  Network  Desijpi  Problems 

The  problem  of  finding  an  optimal  processor  network  configuration  for  a  given 
communication  graph  6  Is  an  Interesting  one.  If  there  are  no  limitations  on  the  number  of 
proceasors  p  and  on  the  number  of  neighbors  per  processor  one  can  build  a  processor 
network  Isomorphlcal  to  the  communication  graph  or  any  network  containing  It.  If  a  imitation 
on  the  number  of  neighbors  per  processor  Is  added,  the  network  described  above  can  be 
modified  by  adding  Intermediate  processors  for  inersaslng  the  number  of  inks  required  by  e 
proceeeor  beyond  the  limit.  A  more  Interesting  problem  Is  the  one  In  which  the  total  number 


of  processors  is  limited  to  p.  We  shall  define  several  related  problems  in  this  category  and 
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Given  a  CQ,  an  integer  p£1,  a  coat  function,  and  the  ooat  function  parameter*;  find  a  PG 
having  p  nodes  auch  that  the  coat  of  the  optimal  distribution  tar  that  graph  la  the  minimum 
among  aH  possible  PG'a. 

Solution:  Finding  the  optimal  distribution  Is  not  required  In  this  problem.  The  optimal  graph  is 
clearly  a  complete  graph  of  p  nodes.  (Not  all  problems  are  hard.)  Note  that  the  degree  of 
each  node  in  the  PG  Is  not  explicitly  bounded  (although  an  Imp  Holt  bound  of  p*1  exists). 
Problems  In  which  the  degree  of  each  node  la  sxpUcitly  bounded  are  dtacuaaed  shortly. 

The  Network-Distribution  Problem: 

Given  a  CG,  a  positive  Integer  p,  a  coat  function,  and  the  coat  function  parameters;  find  a 
PG  having  at  most  p  nodes  and  an  object  distribution  for  that  PG  such  that  the  cost  of  this 
object  dfctribution  Is  the  mlnhaum  among  al  PG's  and  aN  posstale  abject  dtetribuMons  on 
them.  The  difference  between  this  problem  and  the  network  problem  la  that  here  flndhtg  the 
object  dtatributlon  la  required.  The  following  la  a  closely  related  problem. 

The  Network  Decision  Problem: 

Given  a  CG,  a  positive  Integer  p,  a  cost  function,  the  coat  function  parameters,  and  a 
positive  Integer  b;  determine  whether  there  exists  a  PG  having  at  moat  p  nodes  such  that 
the  cost  of  the  optimal  distribution  for  that  graph  Is  at  moat  b. 

By  adding  to  the  above  problems  the  addttional  constraint  that  the  degree  of 
each  node  In  the  PG  can  be  at  moat  L£2  we  get  the  following  problems:  the  limited 


neighbor*  network-distribution  problem,  and  the  limited  neighbor a  network  decision 


problmn. 


Thaoram  2 

The  network  decision  problem  is  NP- complete. 

.  Proof:  We  first  show  that  the  partition  problem  (Given  e  sequence  of  n  positive  Integers 

S=(S1 . Sn)  with  sum  2K;  Is  there  a  subsequence  of  S  that  suew  to  exactly  K?)  is 

polynomlally  transformable  to  the  network  decision  problem.  As  a  CG  we  construct  a  ring  6 
of  n  nodes  and  n  arcs.  The  weight  associated  with  node  I  la  W|«S|(n*1 ).  Each  arc  has  a  cost 
1  associated  with  it.  We  choose  p*2,  b*n,  and  Wy*K(n+1).  This  Is  dearly  a  polynomial 
transformation,  if  S  has  no  partition  then  the  cost  of  the  optimal  solution  Z—  is  at  least  n+1 . 
This  follows  from  the  monotonicity  of  Zjp(X)  and  from  the  fact  that  the  lowest  possible 
Increment  In  X  is  n+1. 

Zn  £  n  Iff  there  is  a  subset  of  the  nodes  of  G  whose  weights  sum  to  exactly 
K(n+1);  i.e..  Iff  S  has  a  partition. 

To  show  that  the  problem  is  in  NP  we  use  the  following  algorithm: 

1 .  {  Choose  a  graph  (define  arcs)  }  -0(p2) 

for  u»1  to  p  do 

arcuu  *  false 
for  v*u+1  to  p  do 

arcyy  «-  choice  ({true,  false}) 
arcyu  -  arcyy 

and 

and 

2.  Prepare  the  distance  matrix  D  -<Xp®) 
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a.  {  Choose  sn  object  distribution  > 

for  1*1  to  n  do  -o(n) 

X)  choice  ({1,.~,p» 

end 

lfZ(x<| . Xp,  C,  D)  £  b  Polynosdal 

then  success 
else  failure 

Since  the  above  algorithm  is  clearly  a  nondetenainistic  potynomiaMy  bounded  algorithm,  the 
problem  is  in  NP.  This  completes  the  proof  of  the  theorem.  Note  that  the  partition  problem 
could  also  be  used  in  proving  theorem  1. 

Corollary  2.1 

The  network-distribution  problem  Is  AfP-hard. 

Corollary  2.2 

The  limited  neighbors  network  decision  problem  Is  A  P-complete. 

Corollary  2.3 

The  limited  neighbors  network -distribution  problem  Is  NP-hartL 

8.6  Approximate  Algorithms 

The  results  of  the  previous  sections  motivated  examination  whether  deterministic 

polynomial  time  approximate  algorithms  can  be  found  to  our  optimization  problems.  First,  let 

us  define  several  terms  (adapted  from  [Ho-78b]).  Let  ZM  be  the  cost  of  an  optimal  solution 

to  an  Instance  of  an  optimization  problem  P.  Let  Z"  be  the  coat  of  a  solution  to  the  same 

Instance  of  P  obtained  by  an  approximation  algorithm  A.  A  la  sn  •-•pproHlmtim  algorithm  for 

Z*-Z- 

a  problem  P  if f  for  every  Instance  of  P,  - —  £  «  for  soma  constant  «.  An  •-opproxlmmo 
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probiin  Is  s  relaxed  version  of  s  given  optimization  problem  P  in  whieh  a  solution  given  by 
an  (-approximate  algorithm  is  required. 

Theorem  S 

The  (-approximate  distribution  problem  Is  MP-hard  tar  all  (X). 

Proof:  We  show  that  the  partition  problem  t  potynomlalty  transformable  to  the  c  approximate 
distribution  problem.  We  use  the  construction  in  the  proof  of  theorem  2.  The  weight 
associated  with  node  I  is  WfSjtn+lXl+fri  )•  Each  arc  has  a  cost  1  associated  with  It.  We 
choose  p*2  and  WT«K(n+1)(1  +  M  ).  Analogously  to  theorem  2,  ZB  J  n  Iff  the  set  S  has  a 
partition. 

If  S  has  no  partition  then  the  cost  of  the  optimal  solution  2^  Is  at  least 
(n+lXl+r.l ).  This  follows  from  the  monotoniclty  of  Z^CX)  and  from  the  fact  that  the  lowest 
possible  increment  In  X  is  (n+lXl+M).  If  S  has  a  partition  but  the  approximate  algorithm 
does  not  return  the  corresponding  object  distribution  but  a  worse  one,  than  the  oast  Z*  Is 
again  at  least  (n+lXl+fri  ).  This  solution  Is  not  sn  (-approximate  solution  since: 

l  <^x_1*.r,1_>~z.»  >  0H1XUMM-1)  .  in  u.. 

Therefore,  the  only  solution  approximating  a  solution  with  cost  Zm  £  n  OP  8  has  a  partition) 
also  has  the  same  cost  Thus,  Z"  £  n  Iff  the  set  $  has  a  partition.  This  completes  the  proof 


i. 

I 


/k 


r 


Theorem  4 

The  (-approximate  network-distribution  problem  Is  AfP-hard  for  aR  (X>. 
Proof:  The  proof  Is  identical  to  that  of  theorem  3. 
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Corollary  4.1 

Tho  (-approximate  limited  nolghbora  network-distribution  problem  is  AfP-hard  for 

a««>0. 

8.7  Heuristic  Objoct  Distribution  Algorithms 

In  this  section  wo  resume  the  investigation  of  the  distribution  problem.  The 
problem  was  shown  to  be  AfP-hard  thus  we  resort  to  heuristic  algorithms.  We  will  present 
several  algorithms  finding  good  object  distributions  (although  in  general  not  the  optimal 
distribution)  and  discuss  their  time  complexity. 

The  common  characteristic  of  all  our  algorithms  is  that  they  are  two  phase 
algorithms.  The  first  phase  consists  of  finding  some  Initial  object  distribution.  The  second 
phase  la  Identical  In  all  the  algorithms;  It  Improves  the  initial  distribution  obtained  by  the  first 
phase.  We  first  describe  the  second  phase  algorithm,  the  distribution  Improvomont 

8.7.1  The  Distribution  Improvement  Algorithm 

The  algorithm  improves  a  given  object  distribution  by  trying  transformations  of 
limited  types  on  the  given  (Sstributlon  as  long  as  the  cost  function  can  be  decreased. 

1 .  Calculate  Z,  set  change  *■  false. 

2.  Search  for  the  first  object  whose  movement  to  another  node  In  PQ  decreases  Z. 

a.  If  no  such  object  Is  found  set  k  *■  2  and  goto  step  3. 

b.  If  an  object  is  found,  move  It,  calculate  Z,  set  change  «-  true  and  goto 
step  2. 

3.  if  then  goto  step  6  else  goto  step  4. 
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4.  Sssrch  for  ths  first  sot  of  K  objsets  whoso  interchange  dsersasss  Z. 

a.  If  no  such  sot  Is  found,  sat  K  *•  K+1  and  goto  stop  3. 

b.  If  a  sat  Is  found.  Interchange  the  objects,  calculate  Z,  set 
change  ►  true  and  goto  step  4. 

5.  If  change*true  and  Kg,>1  then  set  change  *•  false  and  goto  step  2,  else 
terminate. 

The  integer  Km  £  1  is  a  parameter  of  the  algorithm;  the  algorithm  tries  to 
interchange  at  most  Kg,  objects  In  one  step.  Kg,  can  be  chosen  according  to  the  desired 
degree  of  effort  after  examining  the  time  complexity  of  the  algorithm.  It  can  be  chosen  as  a 
function  of  n  and  p  such  that  the  algorithm  terminates  In  reasonable  time.  Since  we  only 
deal  with  integers  and  since  each  time  the  object  distribution  is  improved  Z  decreases  by  at 
least  1,  the  algorithm  is  guaranteed  to  terminate  after  at  most  ZQ  improvements;  where  ZQ  Is 
the  initial  coat  computed  at  step  1 .  The  time  complexity  for  Kg,«1  is  determined  by  step  2 
of  the  algorithm  and  is  0(Zonp).  The  time  complexity  for  Kg,>1  is  determined  by  steps  2  and 
4  and  Is  (XZ^^+Z^)  ■  CXZ0n(nK|"  1  +p)). 

Algorithms  which  try  harder  than  the  above  one  can  be  devised;  e.g.,  instead  of 
Just  interchanging  up  to  Kg,  objects,  moving  up  to  Kg,  objects.  However,  the  complexity  of 
such  algorithms  cannot  be  Justified  especially  since  phase  one  of  the  algorithm  Is  expected 
to  generate  good  Initial  distributions. 

We  now  present  a  sequence  of  Increasingly  Improved  (phase  one)  algorithms  for 
generating  the  Initial  object  distribution. 

T,  . 
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8.7.2  Alt  in  On*  (AIO) 

TMs  algorithm  assigns  all  objects  to  one  node  of  the  PG.  A  reasonable  choice  for 

this  node  is  the  "center"  of  the  network  which  can  be  found  by  calculating  for  each  node  in 

PG  the  function  Ly  *  T.  Djjy.  The  center  is  the  node  having  the  minimum  Ly.  Obviously 
v 

unless  processor  load  cost  is  negligible  in  comparison  to  communication  cost,  the  AIO 
algorithm  presents  the  distribution  improvement  algorithm  a  bad  initial  distribution,  thus 
forcing  it  to  try  hard  (by  choosing  high  enough  Kffl). 

8.73  Best  Fit  (BF) 

The  BF  algorithm  first  orders  all  objects  in  an  object  list  OL  in  some  random  order. 
It  starts  with  an  empty  distribution  and  assigns  objects  from  OL  to  nodes  of  the  PG  one  at  a 
time  according  to  their  order  In  OL  (left  to  right).  After  each  step  only  a  partial  cost 
function  Zp  can  be  computed  since  only  some  of  the  objects  are  assigned.  (The 
components  of  Zp  are  denoted  by  Zp,  Z^,  and  Z^p  in  the  obvious  manner.)  At  each  step  an 
object  is  assigned  in  a  way  which  minimizes  the  increment  AZP;  i.e.,  the  object  is  assigned 
to  the  best  possible  place  (or  one  of  them  In  case  of  ties).  (The  components  of  AZP  are 
denoted  In  the  obvious  manner.)  The  first  object  In  OL  is  assigned  to  the  center  of  PG  (as 
was  previously  defined). 

The  BF  algorithm  produces  a  better  Initial  object  distribution  to  the  second  phase 
than  the  AIO  algorithm,  but  Its  weak  point  is  the  random  order  of  the  objects  in  OL;  the  next 
elgortthm  to  be  presented  improves  this  point. 
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1M  Bart  Fit  (3SF) 

The  SV  algorithm  is  identical  to  the  BF  algorithm  except  that  it  does  not  order 

the  objects  In  OL  randoarty  bat  tries  to  order  them  in  some  promising  way.  The  order  is  best 

explained  in  terms  of  an  infinite  tree  (which  need  not  be  constructed)  derived  from  the  CG 

as  follows.  The  first  node  of  the  tree  is  0|  such  that  H  C..  is  maximum  over  all  L  In  case  of 

J 

ties,  one  of  the  objects  with  maximum  weight  is  selected.  The  sons  of  node  j  in  the  tree 
are  all  its  immediate  neighbors  In  the  CG  ordered  by:  (1)  decreasing  Cj^,  then  by 
(2)  decreasing  weight  Wk.  OL  is  then  constructed  from  the  tree  by  a  breadth  first  order  in 
which  repetition  is  not  allowed.  Since  the  CG  may  be  not  connected,  the  process  is 
repeated  for  ail  connected  components  of  CG  and  the  obtained  lists  are  appended  to  OL  at 
its  end  (the  right  side).  The  order  in  OL  roughly  corresponds  to  scanning  the  connected 
components  of  the  CG  one  at  a  time,  for  each  connected  component  in  rings  of  increasing 
diameter  centered  around  an  initial  node  of  the  component;  i.e..  In  a  spiral  course. 

The  SBF  algorithm  assigns  groups  of  communicating  objects,  thus  as  long  as 
processor  load  cost  allows  it  such  objects  are  expected  to  be  assigned  to  close  nodes  of 
the  CG. 

8.7.5  Limited  Search  SBF  (LSBF) 

In  each  step  of  the  SBF  algorithm  AZP  Is  evaluated  for  all  p  possible  assignments 
of  the  next  abject  0(.  The  LSBF  algorithm  detects  cases  which  occur  in  every  instance  of 
the  problem  in  which  the  search  can  be  limited.  Let  us  first  define  several  terms.  The 
neighbors  of  0|  In  the  CG  which  precede  it  In  OL  are  called  /eft  neighbors.  Node  Py  of  PG  is 
said  to  be  a  /(-order  neighbor  of  node  Pu  if  DUV«K  (K£0). 
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In  order  to  limit  the  search  when  assigning  Oj  the  nodes  o f  the  PS  ere  checked  in 
a  certain  order.  The  first  node  to  he  checked  is  Pu«P(0j),  where  Oj  ie  e  left  neighbor  of  Oj 
with  maximum  C,j  over  all  J.  AZ*  is  evaluated  first  for  Py.  then  repeated^  tor  K-order 
neighbors  of  Py  for  Ml, ...  in  the  worst  case,  all  p  nodes  of  the  PC  ere  checked,  in  the 
following  cases,  toe  search  can  be  tenalnated  eerier. 

(1 )  If  for  some  node  Py,  AZP  »0  then  0}  can  be  aselgned  to  Py;  no  smeiar  change  in 
Zp  can  be  found. 

(2)  If  all  left  neighbors  of  0)  are  assigned  to  one  node  (l.e.,  to  Pu)  and  If  assigning  Oj 
to  some  node  Py  results  in  zfp«0  for  Py,  then  the  best  assignment  so  far  can  be  selected. 
The  reason  Is  that  subsequently  checked  nodes  cannot  yield  a  smaier  Z]J,  and  may  yield  a 
higher  Zf  (In  comparison  to  PJ. 

(3)  In  this  case  (and  the  following  one)  we  assume  that  Y  Cfc  >  0  where  k  ranges 

k 

over  the  left  neighbors  of  0|.  Let  M  be  a  positive  integer;  and  let  S  be  the  set  of  nodes  In 
PG  containing  all  K-order  neighbors  of  Pu  for  MO, ... ,  M.  Assume  that  whan  checking  all 
M-order  neighbors  of  Pu  the  following  conditions  are  satisfied: 

a.  All  left  neighbors  of  0|  are  assigned  to  nodes  In  S;  let  these  nodes  be  P^,  _  ,  Pj. 

b.  The  assignment  of  Oj  to  each  M-order  neighbor  of  Pu  results  in  Zjp«0  for  that 
node. 

Let  Dm  be  toe  maximum  distance  (according  to  toe  distance  matrix  D)  between  any  M-order 
neighbor  of  Pu  and  any  of  Pj,  -.  ,  Pj.  The  search  can  always  terminate  after  checking 
nodes  up  to  and  Including  all  M*Da-order  neighbors  of  Pu,  and  toe  best  assignment  ao  far  be 
selected.  The  reason  Is  that  for  any  M-order  neighbor  of  Pu, 
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k 

where  k  ranges  over  aM  left  neighbors  of  0|.  For  L-order  neighbors  of  Pu  where  L>M+D-|, 

4Z»  i  4ZP  >  D„  T.  C* 
k 

Checking  the  above  contttions  and  keeping  track  of  the  needed  values  can  be  easily 
incorporated  in  the  LSBF  algorithm. 

(4)  The  previous  case  can  be  generalized  by  modifying  requirement  b  to  the  following 

one: 

ba.  The  maximum  AZ^p  resulting  by  assigning  0|  to  M-order  neighbors  of  Pu  is  AZffl. 

Let  D'm  =  Dm  +  rAZm  /  Y.  Cjjjl .  The  search  can  always  terminate  after  checking  nodes  up 

k 

to  and  including  all  M+D'n-order  neighbors  of  Pu  and  the  best  assignment  so  far  be 

selected.  The  reason  is  that  for  any  M-order  neighbor  of  Pu> 

•  Mg  .  4Z?  i  Dm  1  Cllt  .  LZ„  i  D’m  I  C,. 

k  k 

The  rest  of  the  argument  is  analogous  to  case  (3). 

8.7.6  Complexity  of  the  Algorithms 

The  time  complexity  of  the  previously  described  phase  one  algorithms  Is  as 

follows: 

1.  For  AIO  -  0(n). 

2.  For  BF  -  0(np). 

3.  For  SBF  the  time  of  the  Initial  ordering  of  the  objects  must  be  Included.  If  the 
maximum  degree  of  the  CG  is  d  (expected  to  be  a  small  number  for  EBL  programs) 
the  ordering  can  be  done  by  an  0(nd  log  d)  algorithm.  The  SBF  algorithm  Is 
therefore  of  complexity  0(np  ♦  nd  log  d)  *  0(n(p  +  d  tog  d)).  For  most  programs 
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and  networks  the  ordering  overhead  is  therefore  negligible. 

4.  For  LSBF  the  maximum  complexity  is  as  in  the  case  of  SBF,  but  the  average 
complexity  Is  expected  to  be  smaller. 

The  complexity  of  the  distribution  improvement  algorithm  (the  second  phase)  is 
the  dominating  factor  In  the  distribution  algorithm  (on  Its  two  phases)  for  each  of  the 
suggested  phase  one  algorithms.  Thus,  selecting  a  more  complex  phase  one  algorithm  (e.g., 
SBF  or  LSBF)  does  not  increase  the  total  complexity.  Moreover,  since  such  algorithms  are 
likely  to  present  better  distributions  for  the  phase  two  algorithm,  ZQ  is  expected  to  be 
smaller  in  these  cases,  and  thus  the  total  complexity  is  expected  to  decrease. 

8.8  Generating  Initial  Reference  Trees 

After  the  object  distribution  is  found,  reference  trees  should  be  created.  Since 
in  searching  the  optimal  distribution  shortest  path  distances  between  nodes  in  PG  are  used 
for  calculating  Zc,  the  trees  corresponding  to  the  object  distribution  should  be  shortest  path 

treat:  the  tree  corresponding  to  object  0o,  which  connects  P^^  to  P(01) . P(On)  has 

the  property  that  the  tree  path  from  P(0Q)  to  P(0|)  is  a  shortest  path  In  PG  for  !■  1 , ... ,  n. 
Shortest  paths  between  all  pairs  of  nodes  in  the  PG  are  found  while  calculating  the  distance 
matrix  D,  and  these  paths  can  be  used  for  generating  shortest  path  trees.  To  create  a 

shortest  path  tree  connecting  node  PQ  with  nodes  P-j . Pn  the  following  algorithm  can  be 

used: 

1.  Create  an  initial  tree  consisting  of  PQ. 

2.  For  i»1  to  n 

a.  Select  a  shortest  path  connecting  PG  and  P(. 


b.  Starting  at  P(  towards  Pq,  add  nodaa  and  area  froai  tha  aalactad  path 
to  tha  traa  until  a  noda  alraady  in  tha  traa  la  anoountarad. 

Tha  fact  that  tha  rafaranca  traaa  corresponding  to  tha  initial  objaet  dtotilbutton 
are  shortast  path  trees  is  important  If  all  objects  are  assigned  to  one  processor  at  load 
time  (an  approach  we  have  rejected)  they  spread  throughout  the  computation  but  It  seams 
that  the  resulting  reference  trees  cannot  be  optimal  since  they  are  generated  on  tha  baaie 
of  local  decisions.  [Ha-78]  describes  trees  which  are  far  from  being  optimal  that  may  be 
generated  (although  [Ha-78]  describes  batter  approaches). 

In  general,  more  than  one  shortest  path  may  exist  between  two  nodes  in  a  graph, 
thus,  when  creating  the  shortest  path  tree  we  may  have  a  choice.  Is  there  a  goodness 
criterion  for  choosing  among  several  trees?  The  answer  is  positive;  a  tree  having  the 
minimum  number  of  nodes  Is  the  optimal  one  since  it  Involves  the  minimum  number  of 
processors.  This  is  a  second  order  optimization  but  let  us  investigate  It.  The  problem  are 
are  trying  to  solve  is  the  foliowing. 

The  Shortest  Path  Tree  Problem: 

Given  a  PG  G*(N,  A),  a  distinct  node  Pe  in  N,  and  a  set  of  nodes  P^, ... ,  P„  in  N  (PQ  d  P,  tar 
1*1, ... ,  n).  The  distance  associated  with  each  arc  in  A  is  1  (according  to  the  definition  of  a 
PG);  find  the  optimal  shortest  path  traa  T;  i.e.,  a  tree  connecting  Pq,  P1, ... ,  Pn  satisfying: 

(1 )  The  tree  path  connecting  PQ  and  P(  is  a  shortest  path  In  PG  for  1*1 , ... ,  n. 

(2)  The  number  of  nodes  in  T  is  minimum  among  ail  trees  satisfying  (1). 

A  closely  related  problem  Is  the  following. 
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The  Shortest  Path  Tree  Decision  Problem: 

Given  the  same  information  as  in  the  shortest  path  tree  problem,  and  a  positive  Integer  b; 
determine  whether  there  exists  a  shortest  path  tree  having  at  most  b  nodes. 

By  adding  to  the  above  problems  the  additional  constraint  that  the  degree  of 
each  node  In  the  PG  is  at  most  L>3,  we  get  the  modified  problems:  the  limited  neighbors 
shortest  path  tree  problem,  and  the  limited  neighbors  shortest  path  tree  decision  problem. 

Note  that  if  PG  is  a  tree,  all  above  problems  are  trivial  since  there  Is  only  one 
tree  connecting  the  desired  nodes.  The  limited  neighbors  problems  can  be  easily  solved  for 
L°2.  In  this  case  PG  is  either  a  tree  (which  can  be  drawn  as  a  straight  line)  In  which  case 
the  solution  is  trivial,  or  a  ring  in  which  case  the  solution  is  simple. 

Theorem  ff 

The  shortest  path  tree  decision  problem  is  NP- complete. 

Proof:  We  first  show  that  the  set  covering  problem  (Given  a  finite  family  of  finite  sets 
S={Sj},  a  positive  integer  K;  Is  there  a  subfamily  F  of  S  {Fh}  c  (Sj)  such  that  U  Fh  ■  U  Sj 
(i.e.,  S  has  a  cover  F)  and  F  contains  at  most  K  sets?)  is  polynomially  transformable  to  the 
shortest  path  tree  decision  problem.  As  a  PG  we  construct  the  following  graph.  The  nodes 
of  PG  contain:  a  distinct  node  po.  corresponding  to  each  set  Sj  a  node  S'j,  and 
corresponding  to  each  element  Q|  in  U  Sj  (assume  there  are  n  elements  in  U  Sj)  a  node  P|. 
The  arcs  of  PG  contain:  exactly  one  arc  connecting  PQ  and  each  S'j;  and  exactly  one  arc 

connecting  S'j  and  Pj  If  Q|  is  contained  in  Sj.  The  tree  T  should  connect  PQ  with  P.j . Pn; 

we  choose  b*K.  This  Is  clearly  a  polynomial  transformation. 
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The  number  of  nodes  In  T  is  et  most  n+1*K  Iff  S  ties  s  oover  F  oontelwlwg  St  most 
K  sets. 

To  show  that  the  problem  Is  In  NP  we  use  the  foftowing  elgortthm  which  first  selscts  e 
subgraph  T  of  PG  by  choosing  arcs  S|  (among  the  r  arcs  of  PG)  and  the  nodes  with  which 
they  are  incident: 

for  1*1  to  r  do  -0(r) 

S|  ►  choice  ({true,  false}) 

{  S|*true  means:  arc  I  and  the  nodes  with  which  It  is  Incident  are  in  T  } 

end 

If  T(a1t ... ,  ar)  is  a  shortest  path  tree  connecting  PG  end  Pj, ... ,  Pn  and 
the  number  of  nodes  In  T  £  b  Polynomial 

then  success 
elss  failure 

Since  the  above  algorithm  is  clearly  a  nondetermlnistic  polynomialty  bounded  algorithm,  the 
problem  is  in  NP.  This  completes  the  proof  of  the  theorem. 

Corollary  S.1 

The  shortest  path  tree  problem  is  AfP-hard. 

Theorem  6 

The  limited  neighbors  shortest  path  tree  decision  problem  Is  NP- complete. 

Proof:  The  proof  Is  similar  to  that  of  theorem  6,  thus  only  the  required  modifications  will  be 
given.  We  reduce  the  limited  set  covering  problem  (the  set  covering  problem  with  the 
additional  constraint  that  |Sj|  £  3  for  all  j):  this  problem  Is  NP- complete  [Ga-78}.  The 
construction  is  similar  to  that  In  the  proof  of  theorem  6;  however,  Intermediate  nodes  are 
added  to  satisfy  the  limited  neighbors  requirement;  we  choose  L*4. 
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W«  first  add  nodaa  to  tha  sat  of  nodas  {8'j}  to  cwplata  |{8*pj  to  tha  naarost 
higher  powar  of  two  M»2*  (such  that  M£2);  tha  rasultod  axtandad  sat  Is  8".  Wa  than  add 
between  noda  P0  and  nodas  In  Sa  M-2  Intermediate  nodas  that  together  PD  and  tha 
nodas  in  S"  form  a  constant  height  (*)  rooted  binary  tree  (tha  root  Is  Pg)  In  which  ovary 
Intermediate  noda  has  two  sons.  Wa  require  that  tha  tree  T  connects  PQ  with  tha  M-2 
Intermediate  nodas  (in  addition  to  tha  nodas  Pf . P„). 

An  arc  which  previously  want  from  noda  S'j  to  noda  P|  now  goes  to  an 
Intermediate  noda  Py.  Tha  graph  under  construction  should  connect  noda  Pj  with  node  Py  tar 
aH  j.  Tha  limited  neighbors  requirement  Is  handled  analogously  to  tha  way  PQ  was  handled. 
First,  for  each  I,  nodes  are  added  to  tha  set  of  nodas  (Py>  to  complete  |(Py}|  to  tha 
nearest  higher  power  of  two  Nj  (such  that  N|  £  2).  Than,  a  constant  height  Mnary  tree  Is 
created  whose  root  Is  Pj  and  whose  leaves  are  the  above  N|  nodes.  The  height  of  this  tree 
Is  h|«tog2  N,  (where  h(  £  1 ).  This  completes  the  construction  which  Is  dearly  a  polynomial 
transformation.  Observe  that  the  number  of  arcs  on  any  shortest  path  connecting  nodes  PQ 
and  P(  Is  exactly  m*h|. 

The  number  of  nodes  in  T  is  st  most  I  hj  ♦(M-2)>1  •**  *  Ihj  aUMdC  Iff  8  has  a 
cover  F  containing  at  most  K  sets. 

The  other  dhactlon  of  the  proof  is  Identical  to  that  of  theorem  6.  This  oompietee  tha  proof 
of  the  theorem. 

Corodary  8.1 

Tha  limited  neighbors  shortsst  path  tree  problem  Is  NP-hsrd. 
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8.0  A  Heuristic  Initial  Tree  Algorithm 

Thto  section  presents  •  haurtotie  algorithm  to  tho  shortest  path  traa  problem.  Tha 
problem  to  a  second  dagraa  optimization  In  tha  context  in  which  It  arise*  In  our 
implementation  scheme;  thus,  we  wMI  only  describe  a  simple  algorithm.  First,  assume  that 
the  algorithm  for  calculating  the  distance  matrix  0  also  produces  for  each  pair  of  nodes  in 
PG  a  list  of  all  nodes  Included  In  at  least  one  shortest  path  connecting  them.  Then,  observe 
that  the  desired  tree  T  to  contained  In  the  subgraph  of  G  Induced  by  the  nodes  Pq,  Pj,  ...  , 
Pn  and  those  In  the  lists  associated  with  the  pairs  (P^  P1), ... ,  (P^  Pn). 

The  algorithm  operates  on  this  subgraph  G  Instead  of  on  the  whole  PG.  Let  8P 
denote  the  set  of  nodes  Pj , ... ,  P„.  The  algorithm  attaches  a  weight  W(  to  each  node  in  G.  If 
shortest  paths  from  PQ  to  K  distinct  nodes  In  SP  pass  through  node  I  whose  distance  from  PQ 
is  d,  then  W(*(K-1)d;  and  tha  set  of  K  paints  to  denoted  by  SP|.  W,  represents  the  possible 
saving  in  tha  total  numbar  of  nodes  In  the  tree  If  the  paths  to  the  K  nodes  in  SP(  coincide  up 
to  node  I,  In  comparison  to  totally  dto joint  paths.  The  algorithm  to  the  following: 

1 .  If  n»1  then  goto  step  4,  else  proceed. 

2.  For  each  node  I  in  G  evaluate  W(.  Let  node  J  be  the  node  having  the  maximum 
weight  associated  with  It. 

8.  If  Wj  d  0  then  goto  step  5,  else  proceed. 

4.  Hers  all  shortest  paths  are  disjoint.  Return  a  tree  containing  an  arbltrarty  chosen 
path  to  each  nod*  In  SP. 

6.  Recursively  break  the  problem  Into  two  Instances  of  the  shortest  path  tree 
problem  and  merge  the  resulted  trees.  The  two  Instances  are; 

a.  The  distinguished  node  to  Pv  the  new  set  SP*  to  SP  -  SPj  U  {node  J). 
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b.  The  distinguished  node  Is  node  J,  the  new  set  SP1  Is  SPj  -  {node  J}. 

The  algorithm  always  creates  a  shortest  path  tree,  although  not  necessarily  an 
optimal  shortest  path  tree  (as  defined  In  the  previous  section).  In  order  to  see  why  the 
algorithm  always  creates  a  shortest  path  tree  observe  the  following:  For  any  two  nodes  A 
and  B  in  an  undirected  connected  graph,  tha  length  of  the  shortest  path  between  nodes  A 
and  B  Is  equal  to  the  length  of  the  shortest  path  between  node  A  and  node  C  plus  the  length 
of  the  shortest  path  between  node  C  and  node  B,  for  any  node  C  Included  in  some  shortest 
path  between  nodes  A  and  B.  The  algorithm  either  returns  a  shortest  path  (In  step  4),  or 
breaks  a  path  into  two  parts  as  described  above  (in  step  5). 


The  algorithm  seems  to  work  fine  on  many  toy  examples  since  the  weight  function 
criterion  captures  nodes  which  are  good  candidates  for  being  points  at  which  a  path  splits 
to  several  paths.  The  algorithm  falls  In  certain  cases;  one  reason  Is  the  breaking  of  the 
problem  into  separately  solved  subproblems.  This  approach  decreases  the  complexity  of  the 
subproblems  therefore  causes  the  algorithm  to  converge  relatively  fast;  however.  It  lacks 
global  overview  and  that  is  Its  main  drawback. 


^  l 


The  complexity  of  the  algorithm  Is  determined  by  step  2.  Assume  there  are  p1 
nodes  in  G  (the  subgraph  of  PG),  then  the  time  complexity  of  step  2  is  0(np').  Note  that 
pa  £  n+1;  If  n*1  then  step  2  Is  not  executed.  The  maximum  number  of  Instances  of  the 
problem  generated  by  the  algorithm  for  which  step  2  Is  executed  is  at  most  n-1,  thus  the 
overall  complexity  Is  at  most  0(n2p').  The  average  complexity  Is  expected  to  be  lower 
since  when  an  Instance  of  the  problem  results  In  Wj»0  no  new  Instances  of  the  problem  are 
created. 


*  ^ 
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8.10  Pffonwftct  Evaluation 

Appendix  8  davetopa  bounds  on  the  performance  of  a  certain  dess  of  EBL 
programs  on  a  network.  We  use  the  throughput  of  a  program  (the  rate  In  which  events  from 
a  distinguished  event  class  are  used)  as  a  performance  measure.  The  analysis  assumes 
that  various  objects  propagate  in  the  network  subject  to  constraints  on  link  capacity  and 
CPU  capacity.  The  constraints  and  the  function  to  be  maximized  define  a  linear  programaiing 
problem  whose  solution  yields  the  maximum  possible  throughput.  The  analysis  is  done  first 
without  assuming  a  specific  implementation  scheme,  and  then  taking  into  account  our 
manager  based  Implementation  scheme. 

8.11  Sunmary 

This  chapter  has  further  Investigated  the  problem  of  implementing  EBL  on  a 
processor  network.  A  goodness  criterion  for  the  distribution  of  objects  in  a  network  has 
been  developed,  end  several  optimization  problems  Involving  the  distribution  of  objects  In  a 
network  has  been  analyzed.  The  problems,  and  even  approximations  to  these  problems,  are 
NP-hard  as  we  have  proved  in  this  chapter;  several  heuristic  algorithms  have  been 
developed.  The  analyzed  problems  are  not  restricted  to  the  context  of  EBL;  they  are  of 


\ 


general  Interest. 
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9.  Data  Flow  implementation 

TMa  chapter  investigates  strategies  for  implementstion  of  EBL  on  a  data  flow 
proeaaaor.  A  data  flow  procaaaor  (a.g.,  [Da-77])  la  designed  to  achieve  a  highly  parallal 
operation  and  la  tharafora  a  natural  candidata  for  Implamantlng  EBL  which  containa  many 
aourcaa  for  paraNallam.  A  data  flow  procaaaor  la  a  apacial  procaaaor  deaignad  to  run 
programa  expreasad  as  data  flow  schamata  In  a  (graphic)  data  flow  languaga.  Its  principal 
characteristic  Is  that  instructions  ara  axacutad  In  response  to  the  arrival  of  their  operands 
and  there  is  no  notion  of  sequential  control  flow. 

The  architecture  of  a  data  flow  processor  Is  not  unique;  as  a  concrete  example 
this  chapter  uses  the  architecture  Investigated  at  MIT/LCS  Computation  Structures  Group. 
The  architecture  of  the  basic  data  flow  processor  ss  well  as  the  various  types  of  actors 
and  arcs  In  s  data  flow  schema  are  described  In  [De-77].  Figure  9.1  depicts  the  basic  data 
flow  processor. 


Figure  9.1  The  basic  data  flow  processor 
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Several  extensions  to  this  bole  processor  hove  been  Investigated:  [Ac-77]  deecribee 
adding  a  structure  memory  to  the  processor;  [Mi-77]  and  [We-79]  describe  adding 
procedurea  to  the  procesaor.  We  sHM  start  with  the  basic  data  flow  processor  and  examine 
the  extensions  needed  in  order  to  support  EBL  programs. 

The  discussions  in  this  chapter  will  be  conducted  at  two  levels:  the  schema  level, 
and  the  processor  level.  The  first  allows  one  to  abstract  out  details,  and  the  second 
explicitly  deals  with  them.  We  assume  that  the  reader  is  familler  with  the  main  concepts  of 
both  levels. 

Activating  an  Instance  of  en  event  handler  brings  to  mind  activating  an  instance 
of  a  procedure.  Activating  concurrently  several  instances  of  an  event  handler  Is  akin  to 
activating  concurrently  several  Instances  of  a  procedure.  Unfortunately,  the  basic  data 
flow  processor  does  not  support  procedures.  Since  procedures  and  recursion  can  be  easby 
expressed  in  EBL,  any  successful  Implementation  of  EBL  on  a  data  flow  procesaor  wM 
actually  add  these  features  to  the  processor.  Similarly,  solutions  to  the  procedure  problem 
may  make  the  effort  of  implementing  EBL  on  a  data  flow  processor  easier. 

Naturally,  we  have  studkid  the  existing  proposals  for  adding  procedures  and 
recursion  to  die  data  flow  processor  [MI-77,  We-79].  The  principal  difficulty  In 
implementing  procedure  calls  on  a  basic  data  flow  processor  stems  from  the  fact  that  the 
representation  of  programs  In  the  processor  is  impure  [Mi-77];  l.e.,  an  actor  and  its  Input 
tokens  are  stored  together  in  the  Instruction  memory.  Thus,  in  order  to  support  concurrent 
activations  of  a  procedure  one  cannot  simply  allocate  a  distinct  working  area  for  each 
instance  of  a  procedure.  A  reasonable  approach  Is  to  oopy  the  procedure  body  (or  the 
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needed  parts  of  it)  for  each  activation  of  a  procedure  while  relocating  its  addresses; 
relocsting  is  needed  in  order  to  prevent  undesired  interactions  between  several  instances 
of  a  procedure.  This  approach  was  adopted  by  both  [Ml- 7  7]  and  [We- 79]. 


The  common  characteristic  of  both  schemes  is  that  they  incrementally  copy  the 
needed  parts  for  each  activated  instance  of  a  procedure;  thus,  the  cells  associated  with  an 
unselected  conditional  branch  are  not  copied.  Both  schemes  use  a  virtual  memory  and  some 
cache  mechanism.  [Mi- 7  7]  solves  the  relocating  problem  by  using  a  centralized  box  which 
maintains  a  list  of  free  unique  Identifiers.  A  unique  Identifier  is  associated  with  an  instance 
of  a  procedure  and  is  used  as  a  suffix  appended  to  cell  names.  [We-79]  relies  on  the 
existence  of  a  structure  memory  and  uses  unique  identifiers  whose  maintenance  is 
distributed  in  the  processor  and  not  centralized  in  contrast  to  [Mi-77].  For  each  procedure 
instance  an  activation  record  is  created  In  the  virtual  address  space;  the  starting  address 
is  based  on  a  unique  identifier.  Both  schemes  also  add  special  actors  to  the  data  flow 
language  for  supporting  procedure  activations.  [Ml-77]'s  scheme  allows  starting  execution 
of  the  instance  of  the  procedure  even  before  all  parameters  are  available.  If  we  summarize 
the  main  mechanisms  added  to  the  basic  processor  by  the  two  schemes  we  get  the 
following: 


1.  A  memory  system  In  addition  to  the  instruction  memory. 

2.  Structure  processing  capability  (in  [We-79]  only). 

3.  Cache  mechanism  (or  memory  hierarchy). 

4.  Address  mapping  (or  relocating)  mechanism. 

6.  Unique  Identifiers  mechanism. 

6.  Special  function  units  for  handling  procedure  calls. 


Section  9 


-214- 


Data  Flow  Implementation 


The  above  mechanisms  are  essential  to  the  two  schemes.  The  question  arises  whether  one 
really  has  to  add  these  mechanisms  to  the  basic  data  flow  processor  and  to  copy  a 
procedure  body  for  each  procedure  activation  In  order  to  support  procedures  and  recursion. 
The  answer  will  be  clear  after  our  implementation  schemes  are  presented  in  the  following 
sections. 

9.1  The  Processor  Architecture 

The  main  effect  of  allowing  recursive  procedures  in  a  language  is  that  a  program 
may  use  unbounded  storage.  This  is  one  of  the  reasons  why  both  [MI-77]  and  [We-79] 
added  a  memory  system  (whose  address  space  is  much  larger  than  that  of  the  instruction 
memory)  to  the  basic  data  flow  processor.  Since  recursive  procedures  can  be  easily 
expressed  in  EBL,  the  need  for  such  a  memory  system  seems  clear.  From  another  point  of 
view,  an  event  list  in  EBL  can  grow  beyond  any  bound,  and  this  suggests  that  event  lists  be 
kept  in  a  memory  system  which  should  be  added  to  the  basic  data  flow  processor.  Following 
this  approach,  the  modified  data  flow  processor  assumed  in  this  chapter  will  have  tii  j 
architecture  depicted  in  Figure  9.2. 
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result  packets  can  be  sent  to  the  Instruction  memory  In  response  to  one  operation  packet. 
Packets  generated  in  the  memory  system,  carrying  boolean  values  or  signals,  are  sent 
through  the  control  network  analogously  to  the  way  such  packets  are  handled  In  the  basic 
processor;  other  packets  generated  In  the  memory  system  are  sent  through  the  distribution 
network.  The  free  cell  network  supplies  free  storage  cells  to  memory  controiers.  The 
memory  controllers  are  "smart"  controllers;  they  accept  packets  such  as:  write,  read  n 
words,  insert  a  list  element,  delete  a  list  element,  get  a  free  storage  block,  etc. 

The  following  sections  present  several  strategies  for  implementation  of  EBL  on 
the  data  flow  processor.  The  common  characteristic  of  these  strategies  is  that  they 
basically  follow  the  virtual  system  Implementation  scheme  outlined  in  chapter  7;  this  common 
part  of  all  Implementation  schemes  Is  not  repeated  In  this  chapter.  The  main  difference 
between  the  various  strategies  is  the  extent  to  which  possible  parallelism  within  a  program 
is  exploited;  in  particular,  how  many  concurrent  instances  of  an  event  handler  are 
supported. 

9.2  The  One  at  a  Time  Scheme 

This  section  presents  a  very  simple  operation  mode  of  an  EBL  program.  In  this 
mode,  at  most  one  Instance  of  each  event  handler  Is  active  at  any  point  In  time.  Indeed,  this 
mode  does  not  meet  our  design  goals  since  even  the  most  straightforward  form  of 
parallelism  In  an  EBL  program  is  not  exploited.  However,  this  scheme  exposes  some  of  the 
problems  posed  by  the  underlying  processor  architecture  and  Is  upgraded  In  later  sections. 
One  must  observe  that  this  mode  of  operation  Is  semantically  correct.  Even  though  at  any 
point  in  time  several  event  collections  may  match  an  event  handler  heading,  and  thus  more 
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than  one  instance  of  that  event  handler  could  be  active  concurrently,  an  EHM  can  activate 
the  Instances  one  at  a  time;  l.e.,  an  instance  of  an  event  handler  Is  not  activated  as  long  as 
a  previous  Instance  of  that  event  handler  Is  still  active.  The  programmer  has  no  way  of 
forcing  an  EHM  to  activate  more  than  one  instance  of  the  corresponding  event  handler 
concurrently.  (In  fact,  even  the  more  extreme  mode  in  which  at  most  one  event  handler 
instance  is  active  at  any  point  In  time  for  the  whole  program  is  also  possible;  however,  we 
shall  not  pursue  this  approach.) 

In  this  scheme,  each  script  and  each  manager  are  simply  represented  as  data 
flow  schemata  containing  several  special  actors.  A  script  can  be  viewed  as  a  single  Input 
single  output  schema.  The  input  token,  generated  by  the  EHM,  represents  the  activating 
event  collection.  The  output  token  is  a  signal  to  the  EHM  indicating  that  this  instance  of  the 
event  handler  has  terminated.  A  script  schema  contains  several  kinds  of  actors. 

1.  Conventional  actors:  used  for  example  for  evaluating  event  parameters;  these 
actors  are  implemented  by  function  units. 

2.  Memory  actors:  used  for  example  for  reading  parameters  of  activating  events, 
for  getting  free  storage  blocks  for  preparing  new  event  objects,  and  for  writing 
parameters  of  new  events;  these  actors  are  Implemented  by  memory  controllers. 

3.  Actors  used  for  sending  messages  to  ECM's. 

Obtaining  free  storage  blocks  for  events  to  be  caused  by  an  Instance  of  an  event  handler 
need  not  be  done  by  the  instance  of  the  event  handler.  The  EHM  can  prepare  the  memory 
blocks  in  advance  and  pass  them  to  the  instance  of  the  event  handler  when  It  is  activated. 
This  scheme  decreases  the  execution  time  of  the  Instance  of  the  event  handler  but  Imposes 
an  additional  task  on  the  EHM.  If  EHM's  are  not  continuously  busy,  this  scheme  can  decrease 
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the  execution  time  of  the  whole  program. 

A  message  can  be  implemented  simply  as  a  contiguous  block  either  In  the 
Instruction  memory,  or  in  the  memory  system.  Passing  a  message  is  reduced  to  passing  a 
pointer  to  that  block.  The  receiver  decodes  the  message  by  examining  its  fields.  The  input 
to  a  script  schema  and  messages  to  ECM's  can  be  represented  in  this  form.  Actors  for 
sending  messages  to  ECM's  are  used  both  in  scripts  and  in  EHM's.  The  input  to  such  an 
actor  is  a  message  containing  a  field  defining  the  expected  operation,  as  well  as  additional 
information  depending  on  the  requested  operation. 

When  the  requested  operation  is  "add  an  event  object  to  the  event  1st"  the 
additional  information  is  a  pointer  to  a  memory  block  containing  an  event  object  which  has 
been  prepared  by  the  instance  of  the  event  handler.  The  output  ot  the  actor  In  thie  case  is 
a  signal  token  indicating  that  the  actor's  operation  has  been  completed.  As  a  side  effect 
the  actor  normally  adds  the  event  object  to  the  corresponding  event  list.  If  the  event  is  of 
a  non_recurrent  type  it  may  not  be  added  to  the  event  list;  however,  even  in  such  a  case 
the  actor  outputs  a  signal  token.  By  defining  the  ector  in  this  manner  it  becomes 
determinate,  i.e.,  it  outputs  the  same  token  when  activated  with  the  same  input  tokens.  In 
fact,  all  actors  in  a  script  schema  are  determinate;  this  property  is  used  In  section  8.4. 

In  contrast  to  a  script  schema,  a  manager  schema  represents  a  cycle  process. 
This  process  receives  requests  from  several  sources;  these  requests  are  nondetermlnately 
merged  to  one  stream  of  requests  and  then  manipulated.  In  order  to  implement  a  manager 
on  a  data  flow  processor  one  should  first  analyze  several  problems;  for  example: 

1 .  How  to  merge  requests  from  several  sources? 
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2.  Where  and  how  to  keep  the  state  of  a  process? 

The  next  section  investigates  these  problems. 

9.3  Some  Basic  Problems 

This  section  analyzes  several  basic  problems  which  are  encountered  not  only  in 
the  one  at  a  time  scheme,  but  also  in  the  more  efficient  ones.  Similar  problems  are  likely  to 
occur  in  the  implementation  of  many  schemes  involving  concurrent  processes  on  the  data 
flow  processor.  This  section  suggests  several  modifications  to  the  basic  data  flow 
processor. 

9.3.1  The  Merge  Problem 

The  need  to  merge  messages  from  several  sources  into  one  sequence  of 
messages  (i.e.,  to  serialize  the  messages)  arises  in  EBL  in  case  of  managers.  For  example, 
an  ECM  receives  messages  from  EHM's  and  from  instances  of  event  handlers.  There  are 
several  difficulties.  First,  a  message  may  contain  more  than  one  field.  Consider  a  naive 
solution  in  which  a  source  sends  each  message  field  as  a  separate  token  to  a  fixed  place  In 
the  schema  which  is  determined  by  the  message  field  and  the  receiver.  In  general,  this 
solution  does  not  work  since  the  order  of  tokens  in  each  of  these  places  may  not  be  the 
same.  For  example,  in  one  place  the  token  corresponding  to  a  message  from  source  A  may 
precede  the  token  corresponding  to  a  message  from  source  B,  and  in  another  place  the 
reverse  order  may  exist.  The  receiver  which  presumably  takes  one  token  from  each  of  the 
two  places  may  therefore  process  fields  of  different  messages  as  one  logical  unit. 
Therefore,  an  undesired  interaction  of  message  fields  (tokens)  may  occur.  This  difficulty 
can  be  easily  dealt  with  by  assuming  that  the  message  source  (the  sender)  always 
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prsparss  ths  message  fields  In  s  contiguous  memory  block  and  the  Message  Itself  only 
contains  a  pointer  to  this  block.  The  receiver,  after  obtaining  a  pointer  accesses  the  various 
fields  by  using  addresses  relative  to  that  pointer. 

The  second  difficulty  Is  that  the  sources  may  not  be  fixed,  and  the  number  of 
sources  may  vary  and  Is  not  bounded  in  general.  We  first  give  a  solution  to  the  merge 
problem  assuming  fixed  sources  and  then  give  a  solution  assuming  varying  sources. 

Fixed  Sources 

Let  us  first  deal  with  the  case  where  there  are  n  fixed  sources  Sj, ... ,  S„.  Assume  that  we 
have  at  our  disposal  a  nondetermlnate  merge  actor  (see  for  example  [We-79])  having  n 
inputs.  Can  the  schema  of  Figure  9.3  solve  the  problem? 


n 

Figure  9.3  A  nondetermlnate  merge 

At  the  schema  level  the  solution  works  fine.  In  Its  direct  translation  to  a  data  flow  processor 
program,  the  merging  Is  obtained  for  free:  the  destination  address  In  the  Instruction  cell 
representing  S|  Is  R  for  1*1, ... ,  n.  Unfortunately,  this  direct  translation  may  not  work.  The 
reason  is  that  due  to  congestion  of  packets  In  the  distribution  network  deadlocks  (which  are 
better  called  congestion  deadlocks)  can  occur.  The  problem  has  been  analyzed  In  [Mi-763; 
the  solution  Involves  sending  signal  tokens  as  feedback  from  an  actor  to  actors  supplying  Its 
input  tokens.  Applying  this  ides,  the  schema  of  Figure  9.4  can  be  used  to  solve  the  problem. 


L 


TIm  Merge  Problem 


-  221 


Section  0.3.1 


An  arbiter  arbitrarily  chooses  an  Input  arc  carrying  a  token  end  passes  the  token 
to  the  corresponding  output  when  its  signal  input  is  enabled.  When  a  s/g  actor  fires  a  signal 
token  is  created;  dashed  lines  represent  arcs  carrying  signal  tokens.  When  the  receiver 
eccepts  a  token  at  R,  it  returns  a  signal  token  at  Ra  by  means  of  a  s/g  actor  (not  shown  in 
Figure  0.4).  Note  that  here  the  operation  of  the  merge  actor  can  be  really  obtained  for 
free.  If  the  fan-in  of  actors  Is  restricted  (e.g.,  to  2),  as  Is  the  case  when  one  wants  to 
represent  each  actor  by  at  most  one  Instruction  cell,  a  schema  for  merging  n  sources  can  be 
easily  constructed  from  limited  fan-in  merge  subschemata. 

Varying  Sources 

Here,  the  sources  need  not  be  fixed  and  the  number  of  sources  mey  vary  and  is  not 
bounded.  In  this  case,  we  would  like  to  have  a  merge  actor  with  variable  number  of  Inputs, 
with  the  ability  of  cancelling  an  input  which  will  not  be  used  any  more  by  the  source  to 
which  it  was  allocated;  or  the  ability  of  reallocating  an  Input  to  a  new  source.  Without  such 
abilities  the  number  of  inputs  to  the  actor  may  grow  beyond  any  bound  even  if  the  number  of 
sources  at  any  point  In  time  Is  bounded  by  some  fixed  number.  We  do  not  have  a  direct  way 
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of  implementing  such  •  flexible  actor  on  the  dots  flow  processor;  Instead,  we  use  another 
approach. 


Merging  by  simply  having  the  same  destination  address  at  several  eeNs  (the 
sources)  may  causa  congestion  deadlock;  our  solution  Is  to  confine  the  congestion  to  a 
special  area  in  the  processor  where  it  cannot  cause  the  computation  to  halt  due  to 
deadlock.  A  new  distribution  network,  called  the  roquost  network.  Is  added  as  shown  In 
Figure  8.6. 


Figure  B.S  The  data  flew  processor  with  the  request  network 
In  the  new  processor.  In  order  to  send  a  request  to  R  a  packet  containing  the  request  Is 
sent  to  R;  the  packet  is  tagged  as  a  request  pecks*.  Request  packets  are  directed  through 
the  request  network  to  their  destinations.  Congestions  starting  at  the  request  network  awy 
propagate  backwards  to  the  arbitration  network;  In  order  to  eHmtnate  this,  the  arbitration 
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network  lo  spot  Into  two  ports  ouch  that  e  congestion  in  the  reguest  network  cannot  cause 
a  packet  destined  to  a  function  unit  or  to  the  memory  system  to  be  blocked. 

The  reguest  network  provides  a  means  for  s voiding  congestion  deadlocks 
analogously  to  the  way  signals  provide  a  means  for  avoiding  congestion  deadlocks;  both  do 
not  guarantee  deadlock  freedom  since  they  may  be  used  Improperly.  In  order  to  understand 
what  Is  the  proper  use  of  the  reguest  network  let  us  define  several  terms.  We  view  a 
program  as  a  collection  of  processes.  A  process  can  be  cyclic  or  acyclic;  It  can  be 
temporary  or  permanent.  A  packet  from  process  P|  to  process  Pj  can  be  a  request  Ry; 
requests  destined  to  Pj  are  merged  within  Pj.  A  request  Ry  specifies  some  processing  to 
be  done  by  Pj.  Throughout  this  processing  replies  may  be  sent  to  P|.  The  replies  are  normal 
result  packets  or  signals;  however,  requests  sent  to  Pj  are  not  considered  to  be  replies. 
We  assume  that  the  message  associated  with  a  request  packet  contains  addresses  for 
sending  the  replies. 

Any  request  Rj j  whose  blocking  may  cause  Pj  to  stop  processing  other  requests 
until  R|j  arrives  Is  a  critical  request.  A  critical  request  R(j  cannot  be  sent  through  the 
request  network  since  It  may  be  blocked  by  other  requests  destined  to  Pj  or  to  other 
processes.  Let  us  examine  the  following  condition: 

R1.  For  all  I  J,  In  order  to  process  any  request  Fly,  Pj  does  not  have  to  wait  for 
another  request  destined  to  Itself,  or  to  send  any  request  destined  to  another 
process  and  wait  for  any  of  Its  replies  for  completion  of  the  processing  of  Ry. 

If  R1  Is  satisfied  then  there  are  no  critical  requests  and  all  requests  can  be  sent  through 
the  request  network;  no  deadlock  will  result  from  congestion  In  the  request  network.  Of 
course,  deadlocks  due  to  congestions  In  the  distribution  network  must  be  prevented;  the 
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scheme  of  [Mi-76]  can  ba  applied.  Nota  that  Pj  la  allowed  to  cossaunicate  with  othar 
processes  while  processing  a  request  but  not  by  sanding  requests  for  which  replies  are 
needed  in  order  to  complete  the  processing  of  the  request.  Also  observe  that  R1  is  a 
sufficient  condition  but  not  a  necessary  condition.  We  shall  see  (In  section  0.7)  that 
condition  Rl  Is  satisfied  for  the  application  of  the  problem  in  our  Implementation. 

The  request  network  can  be  more  sophisticated  than  a  regular  distribution 
network.  A  packet  can  specify  as  its  destination  one  of  k  adjacent  addresses.  The 
contents  of  these  k  destination  cell  registers  can  ba  merged  according  to  the  fixed  sources 
solution  to  the  merge  problem.  This  approach  associates  a  k  word  buffer  with  a  receiver  of 
requests  and  thus  decreases  congestion  In  the  request  network. 

Another  possibility  for  combining  the  fixed  sources  solution  with  the  varying 
sources  solution  occurs  when  out  of  the  requestors  of  Pj  there  are  n  fixed  sources  and  the 
rest  are  varying  sources.  The  fixed  sources  solution  can  be  used  for  n+k  sources,  where  k 
inputs  to  the  arbiter  are  taken  from  the  request  network.  This  approach  decreases 
congestion  in  the  request  network,  and  in  addition,  the  n  fixed  sources  can  be  served 
faster.  Finally,  note  that  the  varying  sources  case  of  the  merge  problem  occurs  only  In  the 
script  copying  schemes  discussed  in  section  9.7;  for  aH  other  schemes  suggested  the  fixed 
sources  solution  la  sufficient  and  the  request  network  is  not  needed. 
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9.3.2  Tha  State  of  a  Proeaaa 

Tho  basic  data  flow  procoaaor  and  tha  corresponding  data  flow  language  do  not 
contain  adequate  primitives  for  handling  alda  offsets.  In  fact,  tha  data  flow  methodotogy 
avoids  side  affects.  One  can  therefore  expect  sows  difficulties  in  implementing  variables; 
e.g.,  state  variables  of  a  process.  Our  implementation  schemes  involve  processes  (e.g.,  the 
managers)  and  this  motivates  our  interest  Wi  the  problem. 

At  the  schema  level,  state  variables  of  a  process  can  be  kept  as  tokens 
circulating  in  a  cyclic  subschema  having  the  form  of  a  feedback  system  [Le-78];  at  the 
processor  level,  the  state  variables  are  kept  In  the  instruction  memory,  in  order  to  access 
a  state  variable  from  n  different  places  In  a  procars  some  Interface  should  be  edded  to  the 
subschema;  the  aize  of  this  interface  Increases  with  n.  In  addition  to  the  apace  overhead, 
as  n  increases  a  token  trying  to  access  the  process  state  has  to  pass  more  actors, 
therefore  the  time  overhead  also  increases  with  n. 

Since  we  have  added  a  memory  to  the  processor  we  can  use  Its  cells  to  oontaln 
state  variables  in  the  conventional  way.  In  order  to  access  a  state  variable  from  n  different 
places  In  the  process  only  read  or  write  actors  are  needed  without  any  additional 
Interfacing  actors.  Moreover,  If  a  state  variable  Is  concurrently  accessed  from  severe! 
parts  of  a  program  some  synchronization  mechanism  is  needed  in  general;  a  way  to 
Implement  monitors  in  a  data  flow  schema  is  deserfoed  in  [Le-78],  By  devising  powerful 
enough  memory  Instructions  of  the  flavor  read-modlfy-wrtte,  the  need  for  an  additional 
synchronization  mechanism  can  be  eliminated  In  our  scheme  In  many  cases. 
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We  next  suggest  by  means  of  turn  simple  examples  several  modtfleationa  to  the 
data  flow  processor;  these  modifications  make  handling  of  state  variables  in  the  Instruction 
memory  more  efficient. 

933  The  Alarm  Problem 

Suppose  several  sources  In  a  program  can  detect  alarm  conditions.  Each  time  an 
alarm  is  detected  by  some  source,  it  should  write  the  alarm  status  In  a  fixed  alarm  status 
word  associated  with  the  alarm  handler  process.  The  alarm  status  word  is  periodically 
checked  by  the  alarm  handler  process  which  Is  only  interested  In  the  latest  contents  of  the 
alarm  status  word.  The  problem  arises  In  our  Implementation  schemes  when  several  ECM's 
signal  an  EHM  that  it  can  begin  a  search  for  matching  event  collections.  One  can  view  the 
alarm  status  word  as  a  state  variable  and  treat  it  in  one  of  the  ways  suggested  earlier,  but 
more  efficient  schemea  can  be  devised.  Consider  the  schema  In  Figure  0.6. 


Wgero  M  Last  In  evt 

Arc  A  Is  a  apodal  arc  of  unlimited  capacity.  It  stows  the  actor  of  which  It  Is  an  output  arc  to 
fire  oven  If  It  carries  tokens  (In  contrast  to  the  normal  firing  rule).  The  order  of  tokens  on  A 
Is  preserved.  UO  Is  a  special  actor:  when  a  signal  token  arrives  at  Its  signal  Input  It  welts 
untN  there  Is  at  least  one  token  on  Its  Input  arc;  It  then  swallows  all  existing  tokens  on  that 
arc  and  outputs  only  the  latest  one.  This  is  not  a  LIFO  (lest  in  first  out)  actor,  but  a  UO  (lest 
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in  out)  actor. 

The  schema  of  Figure  9.6  exactly  solves  the  alarm  problem;  how  can  It  be 
translated  to  the  data  flow  processor?  The  merging  Is  achieved  Implicitly  as  was  shown. 
The  function  of  the  LIO  actor  can  be  obtained  by  allowing  an  instruction  cell  register  to 
operate  In  the  following  mode: 

1 .  The  register  Is  enabled  after  receiving  at  least  one  packet. 

2.  The  register  is  ready  to  accept  packets  addressed  to  it  as  long  as  the 
instruction  cell  itself  Is  not  enabled.  The  latest  accepted  packet  determines  the 
current  contents  of  the  register. 

3.  The  register  Is  reset  after  an  operation  packet  leaves  the  enabled  Instruction 
cell  to  the  arbitration  network  (i.e.,  the  cell  fires). 

9.3.4  The  Multi-State  Process  Problem 

Suppose  a  process  (e.g.,  an  EHM)  handles  Its  input  tokens  according  to  the 
current  state  of  Its  state  variables;  In  particular,  assume  thst  the  output  of  actor  P  should 
be  directed  to  either  actor  Q  or  actor  R  depending  on  the  state  of  the  process  as  can  be 
seen  In  Figure  9.7. 

w 


How  can  this  behavior  be  achieved  on  the  data  how  processor?  The  problem  can  be 
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treated  as  a  regular  problem  involving  a  process  state  as  was  discussed  earlier.  The  state 
of  the  process  should  be  checked  for  each  token  output  by  P.  If  the  state  changes 
infrequently  relative  to  the  frequency  In  which  tokens  are  output  by  P,  or  If  the  decision 
where  to  send  the  output  of  P  changes  infrequently,  then  there  is  redundant  token 
movement  in  the  schema,  or  excessive  packet  traffic  in  the  data  flow  processor. 

An  attractive  way  is  to  allow  dynamic  modification  of  arcs  In  a  data  flow  schema. 
One  can  specify  that  whenever  an  arc  moves,  tokens  residing  on  it  move  with  it.  This 
however,  leads  to  nondeterminate  computations  and  there  is  no  need  to  add  another  source 
of  nondeterminacy  to  our  language.  Thus,  we  shall  assume  that  whenever  an  arc  moves  It 
carries  no  tokens.  This  approach  amounts  to  dynamic  modification  of  a  program.  In  general 
this  Is  a  dangerous  approach,  but  if  it  Is  done  in  a  controlled  and  tested  manner  by  system 
programs  or  by  output  of  system  programs  such  as  compilers  (in  particular,  an  EBL  compiler), 
it  can  be  quite  useful.  In  order  to  see  how  this  can  be  implemented  in  the  data  flow 
processor  let  us  examine  Figure  9.8. 


Figure  9.8  Instruction  cell  representation 


From  Figure  0.8  it  is  clear  that  switching  the  output  arc  of  actor  P  simply  means 


changing  the  destination  field  in  instruction  cell  P.  Note  that  the  assumption  that  the  arc 
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connecting  P  and  R  carries  no  tokens  means  that  the  input  register  of  R  is  empty,  there  Is 
currently  no  packet  in  the  processor  whose  destination  Is  the  input  register  of  R,  and  there 
is  no  packet  destined  to  a  function  unit  or  to  the  memory  system  which  can  yield  such  a 
packet. 


Allowing  packets  to  be  sent  to  the  register  containing  the  destination  address  of 
a  cell  Is  a  simple  task;  however,  this  means  that  the  register  becomes  a  variable  register. 
Such  a  register  is  normally  reset  after  the  contents  of  the  Instruction  cell  is  sent  to  the 
arbitration  network  [De-77].  This  may  force  us  to  load  (send  a  packet  to)  the  destination 
address  register  of  cell  P  before  each  firing.  This  undesired  behavior  can  be  eliminated  by 
allowing  an  instruction  cell  register  to  operate  in  the  following  mode: 

1 .  The  register  Is  enabled  after  receiving  at  least  one  packet 

2.  The  register  is  ready  to  accept  packets  addressed  to  it  as  long  as  the 
instruction  cell  itself  is  not  enabled.  The  latest  accepted  packet  determines  the 
current  contents  of  the  register. 

3.  The  register  is  not  reset  after  an  operation  packet  leaves  the  enabled  instruction 
cell  to  the  arbitration  network. 

9.3.5  Instruction  Cell  Modifications 

The  modifications  of  the  data  flow  processor  suggested  In  the  previous  two 
subsections  can  be  generalized  by  allowing  the  independent  definition  of  the  following 
orthogonal  modes  for  every  field  In  an  Instruction  cell: 

1 .  Reset  mode:  When  off,  the  cell  field  is  not  reset  after  a  cell  firing  and  the  latest 


contents  Is  used.  When  on,  the  cell  field  is  reset  after  each  cell  firing  and  needs 
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a  new  packet  in  order  to  be  enabled  again  (as  an  option,  several  new  packets 
can  be  specified  instead  of  one). 

2.  Ready  mode:  When  off,  the  cell  field  does  not  accept  a  packet  when  the  field  is 
not  empty  (this  is  the  current  mode  in  the  data  flow  processor).  When  on,  the  ceN 
field  is  ready  to  accept  packets  addressed  to  it  as  long  as  the  instruction  cell  is 
not  enabled.  The  latest  accepted  packet  determines  the  current  contents  of  the 
cell  field. 

It  is  important  to  understand  the  effect  of  the  modifications  suggested  above. 
The  data  flow  processor  has  primitives  which  allow  data  flow  schemata  to  be  translated  to 
it.  However,  it  is  more  general  than  the  schemata  in  the  sense  that  computations  which 
cannot  be  expressed  as  data  flow  schemata  can  be  represented  on  it.  As  an  example, 
suppose  the  only  available  actors  are  identity  actors.  The  schema  In  Figure  9.9  represents  a 
FIFO  of  capacity  two. 


Figure  9.9  A  FIFO 

Figure  9.10  depicts  the  "equivalent"  program  obtained  by  a  direct  translation. 
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Figure  9.10  Cell  representation  of  a  FIFO 

The  behavior  of  the  translated  program  is  nondeterminate  in  contrast  to  that  of  the  schema. 
The  reason  is  that  the  order  of  the  packets  arriving  at  k  Is  not  guaranteed  to  be  preserved 
at  C.  Moreover,  the  translated  program  may  deadlock  in  contrast  to  the  original  schema. 

The  point  we  try  to  make  is  that  the  primitives  of  the  data  flow  processor  allow 
representation  of  a  richer  class  of  computational  behaviors  than  data  flow  schemata.  The 
modifications  suggested  earlier  increase  the  above  difference  and  allow  better 
performance. 

9.4  The  Pipeline  Scheme 

In  the  one  at  a  time  scheme  discussed  earlier,  an  activation  of  an  instance  of  an 
event  handler  has  to  wait  for  the  termination  of  the  execution  of  the  previous  instance  of 
that  event  handler.  This  section  shows  that  there  is  no  need  to  wait  and  the  execution  of 
several  Instances  of  the  same  event  handler  can  proceed  concurrently  In  pipeline  mode.  In 
order  to  understand  why  this  can  be  done  consider  a  data  flow  schema  S  satisfying  the 
following  condition: 

PI.  S  Is  a  single  input  acyclic  data  flow  schema  which  does  not  contain 
nondeterminate  actors,  conditional  actors,  or  procedure  activations. 

For  each  activation  of  S  all  actors  of  S  fire,  and  each  actor  fires  exactly  once.  The  firing 
rules  for  a  data  flow  schema  are  such  that  If  several  activations  of  S  are  executed 


1 


concurrently,  then  tokens  belonging  to  different  activations  do  not  Interact  with  each  other. 
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Furthermore,  If  token  tj  precedes  token  at  the  input  of  S,  then  for  each  actor  A|  having  n 
output  arcs  in  S  the  output  token  n-tuple  corresponding  to  tj  Tj(tj)  precedes  the  output 
token  n-tuple  corresponding  to  T^t^)  in  the  sequence  of  token  n-tuples  output  by  A,;  i.e^ 
the  tokens  order  is  preserved  throughout  the  whole  computation. 

Condition  PI  can  be  relaxed  by  allowing  conditional  actors  (such  as  a  switch 
actor  [We-79])  as  tong  as  the  schema  is  a  well  formed  acyclic  data  flow  schema  (as 
defined  for  example  in  [De-73]).  in  this  relaxed  case,  not  all  actors  of  S  must  fire  for  each 
activation  of  S.  Tokens  belonging  to  different  activations  of  S  do  not  interact  with  each 
other  because  the  schema  Is  well  formed  and  acyclic.  If  token  tj  precedes  token  t^  at  the 
input  of  S,  then  for  each  actor  A|  in  S  if  Tj(tj)  and  Tjd^)  exist  then  Tj(tj)  precedes  Tjd^)  in 
the  sequence  of  token  tuples  output  by  A|.  Note  that  in  this  case,  if  T |(t j)  exists  then  Tj(tj) 
is  a  k-tuple  for  some  0<k£n;  for  a  switch  actor  n*2  and  k=1 .  We  shali  not  pursue  the  use  of 
conditional  actors  any  further  since  our  event  handler  scripts  contain  no  conditional 
elements. 


Condition  PI  can  be  extended  to  cover  the  case  of  a  schema  with  more  than  one 

Input: 

P2.  S  is  an  n  input  acyclic  data  ftow  schema  which  does  not  contain  nondetermlnate 
actors,  conditional  actors,  or  procedure  activations. 

S  is  activated  for  logically  related  token  n-tuples.  Let  ty  denote  the  token  at  Input  I  (1£l$n) 
of  S  belonging  to  token  n-tuple  J.  In  order  to  use  a  general  schema  S  satisfying  condition 
P2  in  pipeline  mode  the  following  condttkxi  must  be  satisfied: 


P3.  t|j  precedes  t^  In  the  sequence  of  tokens  input  by  S  at  input  i,  implies  tp,j 
precedes  t^  in  the  sequence  of  tokens  Input  by  S  at  input  m  for  all  possible  i,  j. 


mmrnmm 
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If  condition  P3  is  not  satisfied,  undeslred  Interactions  among  tokens  belonging  to  different 
logical  input  token  n-tuples  may  occur. 

Condition  P3  may  be  difficult  to  achieve;  for  example,  when  different 
asynchronous  processes  concurrently  activate  S.  Our  solution  to  this  synchronization 
problem  is  to  transform  the  schema  S  having  n>1  inputs  to  a  schema  S'  having  one  input  by 
passing  a  pointer  to  a  contiguous  block  containing  the  n  original  inputs.  This  approach  was 
used  earlier  in  the  merge  problem.  If  however,  condition  P3  can  be  guaranteed,  the 
conversion  to  S'  is  not  needed.  The  advantages  of  using  S  over  S'  are  that  S  contains 
fewer  actors  (less  space)  and  is  executed  faster.  Faster  execution  is  achieved  since 
packaging  of  the  Inputs  into  a  block  and  extracting  them  from  the  block  are  not  needed;  and 
execution  of  S  can  start  before  all  n  inputs  are  available.  One  case  in  which  condition  P3 
can  be  easily  achieved  is  when  a  single  process  creates  the  inputs  of  S. 

An  EBL  script  can  be  represented  as  a  data  flow  schema  whose  inputs  are 
pointers  to  n  event  objects  forming  an  event  collection.  From  the  syntax  of  an  EBL  script  it 
can  be  seen  that  condition  P2  is  satisfied  for  every  script.  Condition  P3  is  also  satisfied 
since  a  single  process  (the  relevant  EHM)  activates  instances  of  the  script.  Thus,  several 
instances  of  an  event  handler  can  be  executed  concurrently  in  a  pipeline  mode. 

Note  that  before  a  schema  S  is  translated  for  the  data  flow  processor  It  should 
be  transformed  to  a  safe  schema,  as  described  In  [MI-76],  In  order  to  avoid  congestion 
deadlocks.  Such  a  transformation  is  not  needed  for  event  handler  scripts  in  the  one  at  a 


time  scheme.  When  the  pipeline  scheme  is  used,  this  transformation  is  required  and  can  be 
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done  by  the  compiler.  All  known  results  sbout  pipeline  techniques  can  be  applied  to  our 
scheme.  For  example,  in  order  to  increase  the  throughput  of  an  event  handler  (the  number 
of  instances  activated  per  unit  time),  identity  actors  can  be  introduced  In  some  branches  of 
the  schema;  this  however,  Increases  the  number  of  packets  sent  per  execution  of  an 
Instance  of  an  event  handler. 

9.5  The  Multiple  Script  Copies  Schemes  * 

In  the  two  schemes  described  in  the  previous  sections  exactly  one  copy  of  a 
script  of  an  event  handler  was  stored  In  the  data  flow  processor.  Each  of  these  schemes 
can  be  modified  by  having  n>1  copies  of  a  script;  n  is  fixed  for  each  event  handler.  By 
extending  the  one  at  a  time  scheme,  we  get  a  scheme  in  which  at  most  n  instances  of  an 
event  handler  can  be  concurrently  active,  the  n  at  a  time  scheme.  By  extending  the  pipeline 
scheme,  we  get  a  scheme  in  which  at  most  n  pipelines  can  be  concurrently  active,  the  n 
pipelines  scheme.  In  both  schemes,  the  EHM  can  start  activating  a  new  instance  of  the 
event  handler  when  there  is  a  free  script  copy.  In  the  n  at  a  time  scheme,  a  script  copy 
becomes  free  once  Its  execution  has  terminated  (all  actors  have  fired).  In  the  n  pipelines 
scheme,  a  script  copy  becomes  free  after  a  signal  has  arrived  from  each  of  its  input  actors 
(or  in  another  approach  from  at  least  one  of  its  input  actors)  to  the  EHM. 

For  both  schemes,  In  the  simplest  approach  the  EHM  uses  the  script  copies  on  a 
round  robin  basis;  the  next  script  copy  to  be  used  Is  always  known,  and  Is  used  only  after  it 
becomes  free.  This  approach  may  cause  unnecessary  delays  since  script  copies  may  not 
become  free  in  the  order  in  which  they  are  used.  In  an  Improved  scheme,  the  EHM  maintains 
a  list  of  free  script  copies;  the  least  recently  used  free  script  copy  Is  selected  by  the  EHM. 
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The  feet  thet  the  script  copies  ere  fixed  implies  thet  each  ECM  can  use  the 
fixed  sources  solution  to  the  merge  problem.  In  particular,  this  means  that  the  request 
network  need  not  be  added  to  the  processor  and  the  architecture  of  Figure  9.2  can  be 
used. 

A  compiler  cannot  make  an  Intelligent  selection  of  n  for  each  event  handler  just 
by  analyzing  a  program.  In  general,  such  a  selection  requires  understanding  of  the  program 
and  knowledge  of  the  values  of  run  time  parameters  or  ranges  of  such  values.  Therefore,  a 
reasonable  approach  Is  to  let  the  user  specify  n  for  each  event  handler.  The  specification 
can  be  done  within  the  program  text  Itself  or  by  some  compile  time  dialog.  By  allowing  the 
user  to  arbitrarily  select  n,  even  the  smallest  program  may  need  unbounded  space  for 
storing  its  code  (the  script  copies).  Unless  virtual  memory  is  added  to  the  processor,  it  may 
be  necessary  to  eliminate  script  copies  at  load  time  in  order  to  meet  the  current  available 
space  in  the  instruction  memory.  Again,  some  load  time  dialog  can  be  imagined  in  which  the 
user  Incrementally  decreases  n  for  various  event  handlers  until  the  complete  program  can 
be  loaded. 

0.6  The  Virtual  Memory  Fixed  Schemes 

All  schemes  presented  so  far  Implicitly  assume  that  the  Instruction  memory  can 
contain  all  managers  and  all  script  copies  together.  The  assumption  may  not  be  valid  for 
large  programs,  for  programs  where  many  copies  of  scripts  are  desired  in  order  to  obtain 
higher  concurrency,  for  processors  containing  a  small  instruction  memory,  or  when  more  than 
one  of  these  cases  occur.  A  natural  solution  to  the  problem  of  a  too  small  Instruction 
memory  in  such  cases  is  to  use  a  sufficiently  large  virtual  memory.  The  virtual  memory  can 


Section  0.6 


236 


The  Virtue!  Memory  Fixed  Schemes 


be  implemented  as  a  hierarchy  of  memories;  for  example,  as  a  two  level  memory.  The 
instruction  memory  serves  as  the  cache,  and  some  packet  memory  serves  as  the  second 
storage  level.  This  modification  of  the  data  flow  processor  allows  al  our  previous  schemes 
to  be  used  without  any  change,  assuming  that  the  cache  mechanism  Is  transparent  to  the 
program;  the  number  of  script  copies  and  their  virtual  addresses  are  fixed,  hence  the  name 
of  the  schemes  outlined  in  this  section. 

Virtual  memories  and  cache  mechanisms  are  described  In  [MI-77]  and  [We-78]  as 
parts  of  their  schemes  for  adding  procedures  to  the  data  flow  processor,  and  in  [Ac-77]; 
similar  mechanisms  can  be  used  In  our  case.  Only  the  virtual  memory  and  cache  mechanism 
of  [Mi-77]  or  [We-70]  are  needed;  and  not  the  additional  mechanisms  supporting  procedure 
calls  such  as:  unique  Identifiers,  or  special  function  units  for  handling  procedure  calls. 

The  existence  of  a  virtual  memory  allows  one  to  use  a  big  number  of  script  copies 
in  the  multiple  script  copies  schemes  in  order  to  increase  concurrency.  However,  using  too 
many  copiea  of  the  same  script  may  cause  unnecessary  trashing.  If  the  replacement 
algorithm  used  by  the  cache  mechanism  Is  known  to  the  compiler,  an  EHM  can  select  the 
next  free  script  copy  in  a  way  which  minimizes  the  likelihood  of  a  cache  miss.  Suppose  for 
example  that  the  least  recently  used  (LRU)  replacement  algorithm  is  used.  Selecting  for  the 
next  free  copy  to  be  used  the  least  recently  used  free  script  copy  as  suggested  in  the 
previous  section  Is  the  worst  approach  when  trashing  occurs;  although  it  Is  the  best 
approach  for  trying  to  keep  all  n  copies  of  a  script  in  the  cache.  Selecting  the  most 
recently  used  free  script  copy  Is  a  better  approach  for  reducing  trashing.  Generalizing  from 
this  (LRU  algorithm)  example,  It  seems  that  the  criterion  used  by  an  EHM  for  selecting  the 
next  free  script  copy  should  be  the  Inverse  of  the  criterion  used  by  the  replacement 
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algorithm. 

9.7  The  Script  Copying  Schemes 

We  stated  earlier  that  solutions  to  the  procedure  problem  can  be  used  in  the 
Implementation  of  EBL.  The  main  characteristics  of  the  two  currently  existing  proposals  for 
solving  the  problem  [Mi-77,  We-79]  have  been  described.  This  section  demonstrates  how 
Miranker's  scheme  ([Mi-77])  can  be  used.  The  idea  is  quite  simple:  we  view  the  script  of  an 
event  handler  as  a  procedure  P,  and  the  activation  of  an  instance  of  the  event  handler  as  a 
call  to  procedure  P.  Miranker's  scheme  cannot  be  employed  in  every  case  since  unsafe 
conditions  may  occur  [Mi-77].  Thus,  we  first  have  to  demonstrate  that  the  use  of  the 
scheme  in  the  context  of  our  implementation  is  safe. 

At  some  level  of  abstraction  an  EHM  can  be  viewed  as  a  loop  containing  a  call  to 
procedure  P.  A  potential  source  for  unsafety  in  such  activation  is  that  several  concurrent 
Instances  of  P  may  return  result  to  the  same  destination.  This  cannot  occur  in  our 
Implementation  since  P  returns  no  values  to  the  calling  EHM.  According  to  Miranker,  a 
sufficient  condition  to  ensure  correct  and  safe  operation  of  his  scheme  In  this  case  Is  that 
all  input  values  for  a  given  activation  of  a  procedure  arrive  before  any  of  the  input  values 
for  the  next  activation  [Mi-77].  Since  all  activations  of  P  occur  within  the  EHM,  the  above 
condition  can  be  easily  guaranteed. 

The  special  properties  of  our  event  handlers  can  be  used  to  simplify  Miranker’s 
scheme.  In  his  scheme,  a  special  actor  RET  Is  used  to  support  returning  of  a  value  from  a 
procedure  to  Its  caller.  Since  no  values  are  returned  In  our  case,  this  actor  is  not  needed. 
A  special  actor  FREE  Is  activated  at  the  end  of  the  execution  of  an  instance  of  a  procedure 


Section  0.7 


-238 


The  Script  Copying  Sen— i— 


with  which  a  suffix  •  has  baan  associated.  Its  tasks  are  purging  al  instruction  s»siory  calls 
having  suffix  #,  destroying  ail  packets  with  a  name  with  suffix  »,  and  returning  •  to  the  list 
of  free  unique  identifiers  (suffixes).  In  our  case,  every  actor  of  the  procedure  fir—  exactly 
once;  therefore,  each  procedure  cell  can  be  purged  Immediately  when  it  thee.  This  approach 
is  reminiscent  of  incremental  garbage  collection.  In  our  case,  this  incremental  garbage 
collection  is  simpler  than  the  garbage  collection  needed  In  Miranker's  scheme  and  provides 
better  space  utilization.  Returning  •  to  the  list  of  free  unique  Identifiers  can  be  done  at  the 
end  of  the  execution  of  the  instance  of  the  procedure  as  in  [MI-77]. 

Another  simplification,  also  based  on  the  fact  that  each  actor  In  our  procedures 
fires  exactly  once,  can  be  made.  There  Is  no  need  to  convert  a  procedure  body  to  a  safe 
schema  as  described  in  [Mi-76]  in  order  to  prevent  congestion  deadlocks.  This  simplification 
results  in  better  space  utilization  and  smaller  communication  overhead. 

An  Interesting  observation  Is  that  in  Miranker's  scheme  If  a  suffix  •  le  Imited  to  n 
bits  then  at  most  N*2n  procedure  calls  can  be  executed  concurrently.  This  limitation  not 
only  restricts  the  degree  of  concurrency  but  also  the  computations  which  can  be  performed 
on  the  processor.  For  example,  factorial(N+1)  cannot  be  computed  by  the  conventional 
recursive  program.  Using  Miranker's  technique  in  our  scheme  does  not  restrict  the  possible 
computations.  When  recursive  procedures  are  expressed  In  EBL,  the  state  of  the 
computation  at  each  Instance  of  a  procedure  Is  kept  in  one  or  more  event  objects  and  these 
have  nothing  to  do  with  suffixes. 


The  schemes  of  [Mi-77]  and  [We-7g]  Incrementally  copy  Instructions 
constituting  the  procedure  body  as  they  are  needed.  Another  strategy  is  to  copy  the  whole 
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procedure  body  at  ceil  time.  The  time  space  tradeoffs  of  the  two  approaches  have  been 
discussed  in  [We-  70]  and  wWI  not  be  repeated  here.  In  our  case,  there  is  additional 
argument  In  favor  of  the  latter  approach:  the  fact  that  ail  actors  of  the  procedure  Are  and 
no  instructions  are  fetched  in  vain  (as  happens  when  the  procedure  contains  conditional 
actors).  Copying  a  whole  procedure  is  simple.  In  the  case  of  [Mi-77]  it  can  be  easily 
achieved  if  a  procedure  occupies  a  contiguous  area  In  the  virtual  memory;  the  compiler  can 
guarantee  such  a  memory  allocation. 

The  idea  of  copying  a  whole  procedure  body  can  be  pursued  to  further  specialize 
the  schemes  of  [Mi-77]  or  [We-79]  to  our  needs.  Since  In  our  case  each  procedure  has 
exactly  one  caller  (the  EHM),  this  caller  can  explicitly  initiate  the  copying  mechanism. 
Furthermore,  each  EHM  can  pre-copy  several  Instances  of  a  script  and  select  one  of  these 
ready  script  copies  when  needed.  This  approach  can  improve  the  time  performance  unless 
too  much  thrashing  occurs. 

All  the  schemes  described  in  this  chapter  (except  in  this  section)  did  not  require 
the  use  of  the  request  network.  However,  In  order  to  use  the  schemes  of  [Mi-77]  or 
[We-79]  the  request  network  is  needed  since  the  sources  generating  requests  to  an  ECM 
are  varying.  Condition  R1  of  section  9.3.1  is  satisfied  since  each  request  arriving  to  an  ECM 
can  be  individually  processed  without  the  need  to  send  or  receive  other  requests.  Thus,  all 
requests  to  ECM's  can  be  passed  through  the  request  network.  As  suggested  at  the  end  of 
section  9.3.1  requests  from  EHM's  to  ECM's  can  be  directed  through  the  distribution 
network  in  order  to  serve  them  faster  and  to  decrease  congestion  in  the  request  network; 
this  can  be  done  since  the  EHM's  are  fixed  sources. 
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9.8  The  Memory  System 

The  srehttocturs  of  the  memory  system  depicted  In  Figure  0.2  hes  been  briefly 
described  earlier.  It  closely  resembles  the  structure  memory  described  In  [Ac-77]  end  our 
memory  system  is  an  adaptation  of  the  structure  memory.  The  structure  memory  as 
described  in  [Ac-77]  does  not  support  side  effects;  in  fact,  avoiding  side  effects  is  one  of 
Its  prime  goals.  For  example,  if  two  pointers  P2  in  the  processor  point  to  the  same 
structure  S,  and  one  of  these  pointers  P^  is  involved  In  an  operation  which  modifies  a 
component  of  the  pointed  structure  the  structure  pointed  to  by  P2  is  not  affected  by  the 
operation.  Conceptually,  the  operation  creates  a  new  structure  although  in  the 
implementation  parts  of  the  two  structures  are  physically  shared. 

If  in  the  previous  example  one  wants  that  P2  will  reflect  the  operation  performed 
on  the  structure  S;  i.e.,  will  point  to  the  modified  structure,  it  cannot  be  achieved.  Thus,  the 
structure  memory  is  not  adequate  for  handling  global  structures.  The  main  use  of  the  memory 
system  in  our  Implementation  scheme  is  for  storing  event  lists.  An  event  list  is  maintained  by 
one  process,  the  ECM,  but  various  pointers  to  its  elements  may  exist  in  the  processor,  in 
EHM's.  There  is  no  sense  in  copying  parts  of  an  event  list  as  a  consequence  of  a  change  in 
the  list,  such  as  deletion  of  an  element,  (as  will  happen  if  the  structure  memory  is  used) 
since  an  event  list  is  global. 

The  reason  for  eliminating  side  effects  from  the  structure  memory  is  avoiding 
nondetermlnacy  In  computations  using  it,  as  explained  In  [Ac-77].  In  our  Implementation 
schemes  the  memory  is  used  by  managers  and  Instances  of  event  handlers  In  ways  which  do 


not  cause  nondetermlnacy  in  addition  to  the  nondetermlnacy  of  the  algorithms  themselves; 


The  Mwory  Syeti 


-  241  - 


Section  9.8 


the  algorithms  nondetenslnacy  Is  taapUed  by  the  semantics  of  tbs  language. 

9.8.1  Storage  Orgmiizatian 

The  memory  system  handles  free  storage  internally.  The  smallest  storage 
allocation  unit  Is  a  ceN.  A  ce U  Is  a  contiguous  group  of  n  memory  words  where  n  is  some 
fixed  (small)  number.  Whenever  a  storage  area  is  needed,  an  operation  packet  is  sent  to 
one  of  the  memory  controllers  requesting  k>1  cells.  The  memory  controller  handling  the 
request  creates  a  block  at  k  cells  by  linking  k  cells  it  obtains  from  the  free  cell  network  in 
one  of  several  fixed  representations.  These  representations  may  include  for  example  a 
linked  list,  or  a  tree  of  some  fixed  branching  factor.  A  block  In  any  such  representation  has 
a  unique  cell,  called  the  block  timed,  associated  with  it;  the  block  head  contains  identifying 
Information  about  the  block  and  its  use  (e.g.,  as  a  list  element).  Once  a  block  Is  formed,  its 
words  are  addressed  as  if  It  is  a  contiguous  storage  area  by  specifying  the  block  head 
address  and  an  offset;  the  memory  controller  traces  the  cells  constituting  the  block  in  order 
to  access  the  desired  word.  The  representation  of  memory  blocks  is  selected  by  the 
compiler.  For  example,  big  event  objects  can  be  represented  as  trees  whereas  small  ones 
as  linked  lists. 

Handling  the  free  storage  can  be  done  as  described  In  [Ac-77].  Each  memory 
controller  has  a  free  cell  list  associated  with  It  (Initially  the  whole  memory  space  la  divided 
among  the  controllers).  Each  memory  controller  always  presents  a  free  cell  from  Its  free  cell 
list  to  the  free  cell  network  (unless  its  list  is  empty).  Whenever  it  needs  a  cell  it  takes  it 
from  the  free  cell  network.  This  network  can  be  viewed  as  an  arbitration  network  which 
passes  free  ceN  addresses  from  memory  controllers  to  memory  controllers.  Whenever  a 
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memory  controller  decides  to  return  a  ceil  to  the  free  storage  it  returns  it  to  its  private  free 
cell  list;  thus,  there  Is  no  need  for  any  coordination  among  different  memory  controllers 
accessing  free  cell  lists.  In  contrast  to  [Ac- 7  7]  where  cells  are  returned  to  free  storage  on 
the  basis  of  reference  counts,  in  our  case  blocks  are  explicitly  returned  to  free  storage  as 
described  in  chapter  7. 

9.8.2  The  Memory  Controller 

The  main  properties  of  the  memory  controller  have  been  already  described.  We 
view  it  as  a  programmable  processor  which  can  be  tailored  exactly  to  the  needs  of  our 
implementation  schemes.  The  operation  packets  it  understands  include  conventional 
instructions  such  as:  write,  read,  read  n  words,  or  read-modlfy-write;  instructions 
concerning  free  storage  such  as:  allocate,  or  return;  instructions  supporting  our 
representation  of  list  elements  described  in  chapter  7  such  as  increment  a  reference  count; 
and  instructions  supporting  requests  that  an  ECM  is  asked  to  handle  such  as:  insert, 
not-needed,  book,  cancel,  acquire,  or  next,  as  defined  in  chapter  f. 

Note  that  in  order  for  a  read-modlfy-write  operation  (e.g.,  test  and  set)  to 
achieve  the  desired  effect  it  should  be  executed  as  a  nondlvislble  command  by  a  memory 
module,  and  not  just  by  a  memory  controller;  otherwise,  interleaving  of  command  packets 
issued  by  several  memory  controllers  may  occur.  Thus,  we  assume  that  a  memory  module  can 
execute  read-modlfy-write  commands  In  addition  to  read  or  write  commands. 

The  memory  modules  constitute  a  shared  memory  accessible  to  managers  and  to 
instances  of  event  handlers.  Thus,  some  of  the  operations  on  an  event  list  which  In  our 
virtual  system  Implementation  scheme  (described  in  chapter  7)  are  executed  by  ECM's  can 
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be  executed  directly  by  instances  of  event  handlers;  for  example,  read  or  not-needed.  This 
decreases  the  number  of  packets  per  execution  of  an  instance  of  an  event  handler. 

When  a  memory  controller  receives  a  not-needed  operation  packet  (Indicating 
that  a  list  element  is  no  longer  needed  by  the  instance  of  the  event  handler)  it  can  always 
return  to  free  storage  all  the  cells  constituting  the  corresponding  memory  block  except  the 
block  head  (which  contains  information  about  the  state  of  the  list  element  and  pointers  to 
its  neighbors).  After  doing  so  it  can  check  whether  the  block  head  itself  can  be  also 
returned  to  free  storage  according  to  the  state  of  the  element,  using  some  nondivisible  test 
and  set  instruction  as  described  in  chapter  7.  Thus,  storage  associated  with  a  list  element 
can  be  partially  freed  even  when  It  Is  still  in  the  acquired  state  and  before  it  enters  the 
deleted  state. 

9.8.3  Congestion  Deedocks  Due  to  the  Memory  System 

The  problem  of  congestion  deadlocks  arose  in  several  places  In  this  chapter.  The 
solution  employed  was  converting  a  schema  to  a  safe  schema  by  using  signal  tokens.  The 
same  problem  may  arise  due  to  unsafe  use  of  the  memory  system.  The  solution  to  this 
problem  Is  identical  to  the  solution  of  the  first  problem.  Each  access  to  the  memory  should 
be  viewed  as  If  done  by  a  memory  actor;  the  subschema  containing  this  actor  must  be  safe. 
From  another  point  of  view,  room  must  be  prepared  for  aN  possible  results  of  a  memory 
operation  packet.  The  memory  system  does  not  spontaneously  send  packets  destined  to  the 
Instruction  memory;  thus,  preparing  room  for  the  results  is  sufficient  for  preventing 
deadlocks  due  to  congestions  in  the  networks  passing  packets  from  the  memory  system  to 
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An  Important  question  is:  can  deadlocks  occur  due  to  congestion  of  packets 
destined  to  the  memory  system  in  the  arbitration  network?  in  order  to  answer  the  question, 
first  observe  that  an  operation  packet  destined  to  the  memory  system  does  not  specify  a 
specific  memory  controller  as  Its  destination.  Thus,  such  a  packet  is  blocked  only  if  all 
memory  controllers  are  currently  full  (l.e.,  cannot  accept  new  operation  packets).  Such  a 
situation  does  not  imply  that  a  deadlock  has  occured  since  a  memory  controller  can  accept 
new  operation  packets  after  completing  the  processing  of  a  previous  one  (It  can  process 
several  packets  concurrently).  The  only  case  in  which  a  deadlock  can  arise  is  when  no 
operation  packet  currently  waiting  In  the  memory  controllers  can  be  completely  processed. 
This  means  that  each  operation  packet  either  waits  because  a  booked  list  element  is 
encountered  (in  case  of  the  packets  next  or  book),  or  because  no  more  free  storage  cells 
are  available.  In  this  situation  the  packets  needed  to  allow  completion  of  the  operation 
packets  currently  waiting  in  memory  controllers  (cancel,  acquire,  or  not-needed)  cannot 
enter  the  memory  system  and  a  deadlock  exists. 

Our  solution  to  the  deadlock  problem  consists  of  the  foliowing  algorithm  executed 
by  a  memory  controller  when  Its  input  queue  Is  full. 

1 .  Move  some  of  the  currently  waiting  operation  packets  to  a  special  buffer  within 
the  memory  controller.  If  there  is  no  room  in  the  special  buffer  then  goto  step  2, 
else  terminate. 

2.  Move  some  of  the  currently  waiting  operation  packets  to  the  memory  itself  after 
obtaining  memory  cells  from  the  free  cell  network.  If  not  enough  free  cells  are 
avaNabie  then  goto  step  3,  else  terminate. 

3.  Send  some  of  the  currently  waiting  operation  packets  back  to  the  instruction 
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memory;  these  packets  will  arrive  again  later. 

Step  3  causes  the  waiting  packets  to  circulate  in  the  system,  thus  allowing  new  operation 
packets  to  enter  the  memory  system.  It  causes  communication  overhead  and  this  is  the 
reason  why  it  is  used  as  the  last  resort  by  a  memory  controller. 

9.9  Performance  Evaluation 

Appendix  C  develops  bounds  on  the  performance  of  a  certain  class  of  EBL 
programs  on  the  data  flow  processor.  As  in  the  case  of  a  processor  network  the  throughput 
of  a  program  is  used  as  a  performance  measure.  The  analysis  assumes  that  the  arbitration 
network  and  the  distribution  network  consist  of  several  routing  networks.  Objects 
propagate  in  the  system  subject  to  constraints  on  routing  network  capacity  and  operator 
capacity.  As  in  the  case  of  a  processor  network  a  linear  programming  problem  whose 
solution  yields  the  maximum  possible  throughput  is  defined.  The  analysis  is  done  first 
without  assuming  a  specific  implementation  scheme,  and  then  taking  into  account  our 
manager  based  implementation  scheme. 

9.10  Summary 

Several  schemes  for  implementation  of  EBL  on  a  data  flow  processor  have  been 
developed  in  this  chapter.  Each  of  these  schemes  requires  a  memory  system  in  addition  to 
the  instruction  memory.  The  memory  system  handles  free  storage  internally  from  efficiency 
reasons;  free  storage  could  be  managed  outside  the  memory  system.  Most  of  our  schemes 
do  not  require  additional  mechanisms  (except  the  memory  system).  Some  of  the  schemes, 
the  script  copying  schemes,  require  additional  supporting  mechanisms:  the  request  network, 
and  the  mechanisms  required  by  the  underlying  procedure  implementation  scheme. 
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Procedures  recursion  and  semaphore  operations  can  be  easily  expressed  in  EBL. 
Therefore,  our  implementation  schemes  actually  add  these  capabilities  to  the  processor. 
The  data  flow  implementation  schemes  outlined  in  this  chapter  can  be  adapted  to  directly 
solve  specific  problems  in  the  data  flow  processor.  For  example.  In  order  to  incorporate 
procedures  In  some  data  flow  processor  language,  procedure  managers  can  be  created.  A 
procedure  manager  can  be  viewed  as  a  combination  of  an  event  handler  manager  and  an 
event  class  manager.  The  event  list  maintained  by  the  procedure  manager  can  simply 
contain  requests  for  procedure  activations. 
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10.  Conclusions  and  Directions  for  Further  Research 

This  chapter  summarizes  the  research,  presents  the  conclusions,  and  suggests 
directions  for  further  research. 

10.1  Summary  and  Conclusions 

The  purpose  of  this  research  has  been  the  development  of  a  language  for  parallel 
programming  in  a  distributed  system  environment,  and  the  investigation  of  strategies  for  its 
implementation  on  multiple  processor  systems.  Several  alternatives  for  the  underlying 
computational  model  have  been  considered.  This  dissertation  has  analyzed  some  of  the 
similarities  and  the  fundamental  differences  between  our  model,  on  one  hand,  and  message 
passing  models  and  process  based  models,  on  the  other  hand;  and  motivated  the  selection 
of  event  semantics  as  the  underlying  model. 

The  fundamental  characteristic  of  our  event  model  is  the  ability  of  an  Instance  of 
a  program  unit  (an  instance  of  an  event  handler)  to  unilaterally  broadcast  messages  (cause 
events)  without  specifying  their  targets.  The  receivers  (event  handlers)  autonomously 
decide  whether  they  are  interested  in  the  messages  (the  information  about  the  nature  of 
the  occurrence  of  the  events)  or  not.  A  receiver  Is  capable  of  performing  a  powerful 
operation:  it  can  remove  from  the  ether,  which  encloses  all  program  units,  one  or  more 
messages  in  an  atomic  action.  Each  instance  of  an  event  handler  only  causes  several 
events,  each  of  which  activating  possibly  several  Instances  of  event  handlers  (i.e.,  creating 
new  activities)  which  cause  new  events;  this  is  the  way  by  which  the  computation  proceeds 


in  our  model. 
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EBL  Is  a  nonprocedural  languege.  As  for  every  nonprocedural  lenguege,  the 
implementation  is  required  to  select  an  algorithm  to  perform  the  operations  indirectly 
specified  by  the  program.  Such  an  Implementation  may  be  Inefficient  especially  if  the 
language  contains  too  powerful  constructs.  Therefore,  the  main  objective  of  this  research 
has  been  to  devise  a  language  which  Is  general  enough  to  allow  expressing  a  wide  variety 
of  computations,  but  is  restricted  enough  to  enable  efficient  implementations.  During  the 
course  of  this  research  many  constructs  and  features  have  been  considered  as  candidates 
to  be  included  in  the  language.  In  some  cases  constructs  have  been  rejected  since  they 
are  inherently  difficult  to  implement  or  Imply  inefficient  implementation  (inefficient  run  time 
code).  In  other  cases  constructs  have  not  been  Incorporated  in  the  language  simply  due  to 
our  desire  to  concentrate  in  this  research  on  the  investigation  of  the  fundamental 
characteristics  of  event  semantics. 

We  have  not  tried  to  achieve  a  minimal  language  since  we  did  not  want  to  obtain 
a  language  which  is  difficult  to  use.  Thus,  the  effects  contributed  by  some  of  the  language 
constructs  can  also  be  achieved  via  others.  For  example,  tags  are  redundant  since  their 
effect  can  be  achieved  by  a  single  global  counter  implemented  as  a  single_use  recurrent 
event  class  identifier.  However,  this  alternative  unnecessarily  serializes  the  process  of 
getting  new  tags  and  complicates  programs. 

Each  construct  or  type  In  the  language  has  an  importa.it  role  which  Justifies  its 
existence.  single_use  recurrent  events  are  the  work  horse  of  the*  language.  They  allow 
modeling  of  all  conventional  language  constructs  discussed  In  chapter  6.  slngle_use 
nonrecurrent  events  are  useful  in  certain  real  time  applications  (e.g.,  for  modeling  an 
elevator  push  button),  for  representing  sets  which  can  grow  and  shrink,  or  for  controlling 
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mutual  exclusion.  multJ_use  recurrent  events  allow  broadcasting  a  message  to  several 
receivers  as  well  as  modeling  mutable  database  records  (together  with  the  last  predicate). 
multi_use  non  recurrent  events  allow  computing  functions  by  tables  and  modeling  sets 
which  cannot  shrink.  Tags  provide  for  distinguishing  between  the  effects  of  different 
instances  of  the  same  event  handlers  as  well  as  joining  several  events  belonging  to  the 
same  logical  computation.  The  predicates  allow  one  to  explicitly  control  the  order  in  which 
instances  of  an  event  handler  are  activated.  Modules  have  no  dynamic  effects;  they 
contribute  to  the  modularity  of  the  language  as  discussed  in  chapter  3. 

The  contribution  of  our  single_use  r  vents  to  the  expressive  power  of  the 
language  is  significant.  In  fact,  they  allowed  us  not  to  include  In  the  language  conventional 
constructs  such  as:  variables,  assignment  statements,  iteration  constructs,  procedures, 
functions,  and  semaphores.  These  constructs  can  be  easily  modeled  in  the  language.  In 
addition,  events  allow  activation  of  parallel  processes,  synchronization  of  parallel 
processes,  mutual  exclusion,  message  passing,  Immutable  objects,  and  the  effect  of  mutable 
objects. 


Even  though  mutable  objects  are  not  part  of  the  language,  their  effect  can  be 
achieved  in  several  unique  ways.  One  way  Is  to  delete  temporary  objects  (forget 
*ingle_use  events)  belonging  to  several  classes,  and  to  create  new  objects  (cause  new 
events)  from  these  classes.  Another  way  Is  to  create  permanent  objects  (cause  multi__use 
events)  in  certain  classes,  and  to  read  the  latest  object  from  a  class  (using  EBL's 


predicates). 
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The  language  design  goals  given  In  chapter  1  have  been  achieved:  EBL  is  simple 
and  Its  few  constructs  are  quite  primitive;  nevertheless,  It  manifests  many  desired 
properties.  Its  expressive  power  is  high  as  discussed  in  chapters  6  and  6.  Modularity 
exists  In  the  language  in  several  forms  as  shown  in  chapter  3.  Encapsulated  program  units 
and  abstract  data  types  can  be  created.  Programs  can  be  developed  both  in  a  top  down 
design  and  in  a  bottom  up  manner.  Parallelism  in  an  EBL  program  is  manifested  in  several 
levels  as  described  In  chapter  3.  New  activities  can  be  easily  spawned  in  a  high  rate, 
synchronized,  and  joined.  These  properties  make  EBL  well  suited  as  a  language  for  parallel 
programming  In  a  multiple  processor  system.  The  language  does  not  contain  constructs 
which  are  inherently  difficult  to  implement  or  imply  inefficient  implementation. 

The  implementation  schemes  developed  in  this  dissertation  are  uncommon  in 
implementations  of  programming  languages.  The  basic  Implementation  scheme  Is  especially 
designed  for  distributed  systems;  it  involves  many  managers  communicating  with  each  other 
and  operating  without  any  centralized  control.  Unlike  implementations  involving  one  global 
manager  the  role  of  a  manager  in  our  scheme  is  limited;  It  can  be  either  an  event  class 
manager  or  an  event  handler  manager. 

This  thesis  is  yet  another  example  of  the  fact  that  more  difficulties  are 
encountered  in  distributed  system  implementations  than  in  the  case  of  single  processor 
system  implementations;  this  Is  the  price  paid  for  achieving  higher  concurrency  (as  well  as 
other  advantages).  An  example  of  an  operation  that  Is  more  difficult  to  implement  in  a 
distributed  system  is  locking  of  objects.  We  have  developed  a  two  phase  locking 
(acquisition)  algorithm  in  which  deadlocks  are  prevented.  In  contrast  to  many  existing 
algorithms  which  prevent  deadlocks  by  defining  a  total  order  on  all  objects  to  be  locked,  our 
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scheme  only  defines  a  partial  order  on  all  object  classes.  The  advantage  of  this  scheme  is 
that  objects  can  be  locked  by  a  requestor  concurrently  and  not  sequentially  as  In  other 
algorithms. 


The  investigation  of  schemes  for  implementation  of  EBL  on  a  processor  network 
has  led  to  several  optimization  problems  involving  distribution  of  objects  In  a  network.  These 
problems  are  of  general  interest  and  are  not  restricted  to  the  context  of  EBL.  We  have 
proved  that  the  optimization  problems  and  even  approximations  to  these  optimizations  are 
A//*-hard,  and  suggested  heuristic  algorithms. 

Various  schemes  for  implementation  of  EBL  on  a  data  flow  processor  have  been 
suggested.  The  existence  of  these  schemes  In  addition  to  the  network  implementation 
schemes  shows  that  the  scope  of  the  language  is  not  restricted  to  a  specific  computer 

architecture,  and  that  the  language  does  not  need  special  hardware  to  support  Its 

/ 

Implementation.  An  implementation  of  EBL  on  a  data  flow  processor  actually  adds  to  the 
processor  certain  capabilities  which  have  been  research  subjects  In  the  last  several  years 
(e.g.,  procedures  and  semaphores),  since  these  can  be  easily  expressed  In  the  language. 

One  should  note  that  implementations  of  the  language  (in  particular  our  manager 
baaed  implementation  scheme)  on  geographically  distributed  systems  are  likely  to  be 
bwfflcient  because  of  the  delays  which  are  inherent  In  such  systems. 

The  language  seems  to  be  useful  for  applications  Involving,  for  example, 
application  of  resources  (as  can  be  seen  from  chapter  6).  However,  application  of  the 
lenguage  to  specific  domains  can  benefit  from  special  constructs.  For  example,  real  time 


applications  could  make  use  of  constructs  which  allow  one  to  specify  time  constraints  such 
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as  the  maximum  latency  between  events.  However,  schemes  which  guarantee  these 
constraints  must  be  devised. 

10.2  Directions  for  Further  Research 

This  research  can  be  pursued  both  at  the  language  level  and  at  the 
implementation  level.  The  language  described  in  this  thesis  contains  only  a  small  set  of 
constructs.  These  constructs  allow  one  to  model  quite  easily  many  other  constructs  but  it  is 
not  realistic  to  assume  that  a  programmer  would  like  to  explicitly  translate  such  constructs 
each  time  they  are  used.  In  order  to  make  the  language  more  practical  It  should  be 
supplemented  by  additional  constructs.  The  approach  of  chapter  6  can  be  pursued,  or  the 
event  semantics  might  be  incorporated  in  some  existing  language. 

A  natural  future  step  is  an  implementation  of  the  language  on  some  multiple 
processor  system,  e.g.,  the  MuNet  [Wa-78b].  Once  the  language  is  implemented  Its 
usability  can  be  determined.  Various  measurements  can  then  be  performed  to  determine 
the  overhead  introduced  by  our  managers  and  the  efficiency  of  the  manager  based 
implementation  scheme.  Another  way  to  evaluate  the  Implementation  scheme  is  by  means  of 
a  simulation.  Another  research  direction  Is  to  design  a  multiple  processor  architecture  which 
directly  supports  the  language. 

There  are  Issues  which  have  not  been  addressed  In  the  thesis  and  one  may  want 
to  investigate  how  they  affect  the  results  of  this  research.  Examples  of  such  issues  are: 
reliability  of  the  underlying  system,  and  concurrent  execution  of  several  programs  on  the 


same  system. 
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Will  multiple  processors  speak  EBL?  Many  arguments  favoring  a  positive  answer 
have  been  given  In  this  dissertation.  However,  the  development  of  languages  for  parallel 
programming  in  a  distributed  system  environment  will  not,  and  should  not,  terminate  with  this 
research.  Additional  languages,  perhaps  more  attractive,  can  be  expected. 
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Appencflx  A  -  The  Formal  Syntax 

This  appendix  contains  a  formal  definition  of  the  syntax  of  EBL  The  order  of  the 
sections  is  close  to  that  of  chapter  4  for  a  convenient  reference.  The  notation  is  explained 
at  the  beginning  of  chapter  4. 

A.1  Identifiers  and  Numbers 

<ident>  <letter>  {  <letter>  |  <diglt>  |  _  ) 

<unsigned__number>  (  <digit> 

<character>  ::=  <digit>  |  <letter>  |  <special_character> 

<digit>  0  |  1  |2|3|4|6|6|7|8|9 
<letter>  a  | ...  |  z  |  A  |  ...  |  Z 

<special_character>  ♦|-|"|/|*|<|>|(|)|[|]|{|}|- 

A.2  Constants 

<constant>  <unsigned_constant>  |  {  +  |  -  }i  <unsigned_number> 
<unsigned_constant>  <unsigned_number>  |  '<character>  |  true  |  false 

A.3  Types  and  Type  Identifiers 

<type>  <slmple_type>  |  <event_type>  |  <type_ldent> 

<simple_type>  <basic_type>  |  tag 
<basic_type>  lot  j  booi  |  char 
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<evenl_type>  {  singie_use  |  multi_u*a  {  recurrent  |  non_recurrent 

event  {  (  <type_liat>  ) 

<type_list>  <type>  (  ,  <type>  ) 

<type_ident>  ::=  <ident> 

A.3.1  Type  Identifier  Definition 

<type_def Inition >  <type_ident>  {  ,  <type_ldent>  }  ==  <type_Hst>  ; 

A-4  Declarations 

<declaration>  ::=  <type_def inition >  | 

<event_class_declaratlon>  | 

<tag_declaratlon>  | 

<event_handler>  | 

<module> 

A.4.1  Event  Class  Identifier  Declaration 

<event_claas_declaratlon>  s:*  <event_class_identifier> 

{  ,  <event_class_identifier>  }  :  (  <event_type>  |  <type_ldent>  }]  ; 
<event_claaa_ldentifier>  <ident> 

A.4.2  Tag  identifier  Declaration 

<tag_declarat!on>  <tag_ldent>  {  ,  <tag_ident>  }  :  tag  ; 

<tag_ldent>  <ldent> 
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A.6  Expressions 

<exp>  <basfc_exp>  J  <non_baaic_exp> 

<baaic_exp>  <lnt_exp>  |  <bool_exp>  |  <char_exp> 

A. 5.1  Integer  Expression 

<lnt_exp>  '  |  -  J1  <int_term>  {  <lnt_adop>  <lnt_term>  } 

<lnt_adop>  ::*♦(- 

<int_term>  <lnt_factor>  {  <lnt_mop>  <lnt_factor>  } 

<lnt_mop>  ::*  *  |  /  |  |  mod 

<int_factor>  <unslflned_conatant>  |  <formal_parameter>  |  (  <int_exp>  )  | 

aba  (  <lnt_exp>  )  |  ord  (  <char_exp>  ) 

A.5.2  Boolean  Expression 

<bool_exp>  <bool_term>  {  <boo!_adop>  <bool_term>  ) 

<bool_adop>  or  |  xor 

<bool_term>  <bool_factor>  (  <bool_mop>  <bool_factor>  } 

<bool_mop>  and 

<bool_factor>  {  not  <bool_prlmary> 

<bool_prlmary>  <conatant>  |  <formal_parameter>  |  <bool_relatlon>  | 

(  <boo)_exp>  ) 

<bool_relatton>  <exp>  (  ■  |  <>  }{  <exp>  | 

<lnt_exp>  {  <  |  <*  |  >■  I  >  }i  <lnt_exp> 
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A.5.3  Character  Expression 

<char_exp>  <constant>  |  <formal_parameter>  |  chr  (  <int_exp>  ) 

A.5.4  Non-Basic  Expression 

<non_baslc_exp>  <event_c!ass_ldentlfier>  |  <tag_1dent>  | 

<formal_parameter> 


A.6  Event  Handler 

<event_handler>  ::=  on  <event_handler_heading>  <event_handler_body>  end  ; 

A.6.1  Event  Handler  Heading 

<event_handler_heading>  <event_descriptor_list>  {  where  <conditlon> 
<event_descriptor_list>  <event_descrlptor>  {  a  <event_descrfptor>  } 
<event__descriptor>  ::=  <c)ass_class_identifier>  {  (  <formal_parameter_l!st>  )  J1 
<forma1_pcrameter_list>  <formal_paramctor_section> 

{  ,  <formal_parameter_section>  } 

<formal_parameter_sectlon>  ::=  <formal_parameter>  (  ,  <formal_parameter>  } 

s  <type> 


<formal_parameter>  <ident> 
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A.6.2  VA/here  Clause  Condition 

< condition >  <bool_exp>  | 

(  <booi_exp>  )  {  a  <predicate>  }1  | 

<predicate>  {  a  <predlcate>  } 

<predicate>  ::=  exist  (  <event_class_ldentifler>  )  | 
none  (  <event_class_ldenttfier>  )  | 
min  (  <int_exp>  )  |  max  (  <lnt_exp>  )  | 
first  (  <event_descriptor>  )  |  last  (  <event_descrlptor>  ) 

A.6.3  Event  Handler  Body 

<event_handler_body>  ::*  {  <tag_declaratk>n>  ) 

{  par_cause  |  seq_cause  }]  <script> 

<script>  ::=  {  <event>  {  ;  <event>  } 

<event>  ::=  <class_deslgnator> 

{  (  <actual_parameter>  {  ,  <actual_parameter>  }  )  }^ 
<class_designator>  ::=  <event_class_ldentifier>  |  <formal_j»arameter> 
<actual_parameter>  <exp> 

A .7  Module 

<module>  module  <module_interface>  <module_body>  end  ; 

<module_lnterfaco>  (  Import:  {  <ldent_llst>  |  all 

(  export:  (  <ldent_llst>  |  all  }]  ; 

<ldent_llst>  ::■  <ldent>  (  ,  <ident>  ) 

<module_body>  (  <declaratlon>  } 


Program 


A.8  Program 

<program>  <module_body> 
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Appendix  B  -  Network  Performance  Evaluation 

This  appendix  develops  bounds  on  the  performance  of  a  certain  class  of  EBL 
programs  on  a  network.  It  first  describes  our  view  of  the  network  and  defines  the  class  of 
programs  captured  by  our  model.  Then,  a  method  for  computing  performance  bounds  which  Is 
not  based  on  a  specific  Implementation  scheme  is  presented.  Finally,  a  method  for  computing 
performance  bounds  which  takes  Into  account  our  manager  based  Implementation  scheme  Is 
developed. 

B.1  The  Model 

Our  view  of  the  network  is  basically  as  described  in  the  beginning  of  chapter  8; 
however,  we  do  not  assume  that  all  processors  are  Identical.  The  links  In  this  model  ere 
directed  since  we  distinguish  in  the  analysis  between  the  flow  of  objects  from  node  n  to 
node  n'  and  the  flow  of  objects  from  node  n'  to  node  n.  Each  undirected  link  in  the  original 
network  is  therefore  viewed  as  a  pair  of  directed  links  in  the  model.  The  network  imposes 
constraints  on  the  rate  in  which  computations  can  be  performed.  Our  analysis  takes  into 
account  two  constraints:  CPU  capacity  and  link  capacity.  CPU  capacity  is  derived  from  the 
speed  in  which  the  processor  can  execute  Instructions.  The  capacity  of  a  link  is  derived 
from  its  bandwidth  (its  speed).  Propogation  delay  along  links  is  not  taken  Into  account;  we 
assume  it  is  negligible. 

The  network  contains  a  set  of  input  links  through  which  Information  from  the 
external  world  arrives,  and  a  set  of  output  links  Lg^  through  which  Information  Is  sent  to 
the  external  world.  The  information  entering  the  system  through  consists  of  events  from 
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a  distinguished  event  class  denoted  by  ejn.  The  information  leaving  the  system  through  Lout 
consists  of  events  from  another  distinguished  event  class,  denoted  by  For  simplicity 

we  assume  that 

We  assume  a  special  class  of  programs.  Instances  of  event  handlers  are 
activated  In  response  to  occurrences  of  events  from  the  class  e^.  They  perform 
computations  by  activating  other  instances  of  event  handlers  and  cause  events  from  the 
class  All  event  class  Identifiers  are  of  single_use  recurrent  types.  The  program  uses 
events  from  the  class  e^  and  causes  (as  output)  events  from  the  class  As  a 

performance  measure  of  the  program  we  will  examine  the  throughput  Z  of  the  program:  the 
rate  In  which  events  from  the  class  e|n  are  used.  Other  performance  measures  are 
possible;  e.g.,  the  delay  between  the  time  an  Input  event  arrives  and  the  time  all  related 
output  events  leave  the  system.  Throughput,  however,  is  easier  to  analyze  and  captures  an 
important  system  aspect.  Our  throughput  analysis  can  be  applied  to  any  EBL  program 
satisfying  the  fallowing  conditions: 

1.  The  program  contains  two  distinct  event  class  identifiers  e^  and  as 

explained  earlier. 

2.  All  event  class  Identifiers  are  of  ainglo_use  recurrent  types. 

3.  No  formal  parasieters  of  type  event  appear  as  class  designators  in  the  script  of 
any  event  h amber. 

4.  For  each  event  class  Identifier  e,  the  total  frequency  in  which  events  from  class 
e  are  caused  by  the  program  or  enter  the  system  equals  the  total  frequency  in 
which  events  from  class  a  are  used  by  the  program  or  leave  the  system. 

Condition  1  can  be  easly  relaxed;  we  shall  not  do  so.  Conditions  2  and  3  are  relaxed  later. 
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Condition  4  is  needed;  otherwise,  either  the  program  is  not  executed  correctly,  or  events 
accumulate  in  the  system  without  any  bound  on  their  number.  The  following  program,  for 
example,  cannot  be  analyzed  In  our  model: 

0,1  ein 

par_cause  e^  ;  e 

end  ; 

The  reason  is  that  over  the  long  term  the  number  of  accumulated  (unused)  events  from 
class  e  grows  beyond  any  bound. 

B.2  Maximum  Possible  Throughput 

A  method  for  computing  a  bound  on  the  maximum  possible  throughput  of  a  given 
program  on  a  given  network  Is  developed  now.  (The  techniques  of  this  section  are  based  on 
the  analysis  in  [Ha-79].)  Some  qualifications  on  the  method  are  given  later.  Several  copies 
of  the  script  of  each  event  handler  h  exist  in  nodes  of  the  network.  Whenever  an  instance 
of  an  event  handler  is  executed,  event  objects  are  created  according  to  the  script  of  the 
event  handler.  These  event  objects  propagate  through  the  network  links  until  they  are 
either  used  by  an  instance  of  some  event  handler  or  leave  the  system  through  the  output 
links  (if  they  belong  to  e,^). 

Event  objects  propagate  in  the  network  subject  to  constraints  on  link  capacity 
and  CPU  capacity.  The  constraints  and  the  function  to  be  maximized  define  e  linear 
programming  problem  whose  solution  yields  the  maximum  possible  throughput.  No  higher 
throughput  is  possible  since  for  each  execution  of  an  instance  of  an  event  handler  only  CPU 
time  for  preparing  event  objects  Is  taken  Into  account;  no  overhead  of  finding  and  acquiring 
matching  event  collections  exists.  Events  move  in  the  network  in  the  optimal  manner 
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(yielding  maximum  throughput)  as  If  they  are  guided  by  some  aU  knowing  power  which 
consumes  no  computational  resources.  Table  B.1  defines  the  terminology  to  be  used  In  the 
sequel.  Some  of  the  identifiers  are  only  used  in  later  sections. 


®ln 

h 

eli 

L 

I 

hn  *Lout) 
n,  n' 

Kn) 

0(n) 


Txf 

m. 

«h 


m,  m-j ,  ^2 
M-n 


an  event  class  Identifier 

the  input  (output)  event  class  Identifier 

an  event  handler 

e  appears  in  the  event  descriptor  list  of  h 
the  set  of  links  in  the  network 
a  link  in  the  network 

the  set  of  input  (output)  links:  Ljn£L  (Lq^cL) 

nodes  in  the  network 

the  set  of  links  entering  node  n 

the  set  of  finks  leaving  node  n 

the  number  of  events  from  class  e  caused  by  an  instance  of  h 

the  number  of  events  from  class  e  used  by  an  instance  of  h 

the  frequency  In  which  events  from  class  e  are  caused 

the  frequency  in  which  instances  of  h  are  executed 

the  frequency  (flow)  of  messages  of  class  x  over  link  I 

the  frequency  In  which  Instances  of  x  are  executed  on  node  n 

CPU  tisw  to  execute  an  instance  of  h  on  node  n 

CPU  time  to  receive  a  message  of  class  x  on  node  n 

CPU  time  to  send  a  message  of  class  x  from  node  n 

the  time  taken  by  a  message  of  class  x  traversing  Nnk  I 

the  ECM  of  e 

the  EHM  of  h 

managers 

1  Iff  manager  m  resides  on  node  n,  else  0 


Classes  denoted  by  x: 

•>  h,  ma>  mh  as  defined  earlier 

n^n'  a  message  from  m^  destined  to  node  n’  for  activating  an  instance  of  h 

K0mh  a  message  from  m0  to  m^  (defined  only  if  e*h) 

<yie  a  message  from  mh  to  me  (defined  only  If  e'Ti) 

me*-out  a  message  from  me  to  the  output  links 


Table  B.1  Network  throughput  terminology 


Section  B.2 


-  270  - 


Maximum  Possible  Throughput 


The  difference  between  the  input  flow  of  messages  from  class  x  to  node  n  and 
the  output  flow  of  messages  from  class  x  from  node  n  appears  in  several  equations.  The 
following  function  evaluates  it: 

D<Fxl>  ~  Fxl  "  Fxl 
W(n)  kO(n) 

The  linear  programming  constraints  are  presented  now.  Conservation  of  events  must  hold 
for  all  e,  n: 

°(Fa|)  -  X  uehFhn  ♦  X  cehFhn  ■  ° 
h  h 

Link  capacity  cannot  be  exceeded;  thus,  for  all  I: 

B-2  IVai^l 

e 

The  processing  performed  on  node  n  (communication  overhead  and  execution  of  Instances  of 
event  handlers)  cannot  exceed  the  CPU  capacity: 

B.3  X  *  X  BenFej  +  X  phnFhn  S  1 

e>l(n)  e,kO(n)  h 
Only  events  of  class  ein  can  flow  on  input  finks: 

B.4  Fe(  ■  0  for  all  e#e)n  and  bl|n 

SfmUarfy,  only  events  of  class  can  flow  on  output  links: 

B.6  Fe(  ■  0  for  all  e^eQ(Jt  and 

All  frequencies  and  flows  must  be  non-negative;  thus,  for  ad  e,  h,  I,  n: 


B*®  Fel*  Fhn  *  0 

Finally,  the  objective  function  to  be  maximized  Is: 
B.7 


••Mn 


We  do  not  claim  that  the  above  scheme  yields  the  maximum  possible  throughput 
of  a  program  over  all  possible  Implementation  schemes  of  EBL  on  a  network.  One  reason  is 
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that  we  have  assumed  that  an  Instance  of  an  event  handler  Is  activated  and  fully  executed 
on  the  same  node.  Implementations  in  which  the  script  itself  is  distributed  in  the  network  are 
possible.  Our  analysis  can  be  extended  to  include  such  implementations  as  well.  Another 
reason  is  that  higher  throughput  for  a  given  program  may  be  achieved  by  optimizing  the 
program  (not  Its  implementation);  e.g.,  by  eliminating  redundant  events,  as  discussed  in 
chapter  7.  Suppose,  for  example,  the  program  consists  of  n  event  handlers  of  the  form: 
on  ej 

par_cause  ej+1 
end  ; 

for  1=1 . n,  where  ei=ejn  and  en+i=eout.  This  program  can  be  optimized  (by  a  compiler)  to 

the  following  one,  thus  yielding  a  higher  throughput: 
onejn 

par_cause  eQUt 
end  ; 

Thus,  optimized  programs  may  yield  a  throughput  which  is  higher  than  the  one  suggested  by 
our  throughput  analysis. 

As  a  special  case,  the  throughput  analysis  can  be  applied  to  the  virtual  system  of 

chapter  7,  assuming  a  fixed  number  of  processors.  Each  link  in  the  virtual  system  has  an  • 

j 

unlimited  capacity;  thus,  we  substitute  in  B.2  T0j=O  for  all  e,  I.  Also,  there  Is  no  1 

1 

communication  overhead  in  the  virtual  system;  thus,  we  substitute  in  B.3  Ren=S0n=O  for  all  j 

f 

e,  n.  { 

I 

i 

It  is  interesting  to  examine  how  the  linear  programming  approach  handles  data 
dependency.  Where  clauses  are  not  reflected  in  the  model.  The  optimal  linear  programming 
problem  solution  yields  flows  of  events  and  frequencies  of  execution  of  instances  of  event 
handlers  from  which  some  data  dependency  properties  can  be  deduced.  The  optimal  solution 
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assumes  that  the  various  events  have  the  properties  (parameters)  needed  for  achieving  the 

maximum  throughput.  Consider,  for  example,  the  following  program  for  computing  factorial: 

on  ejn  (n:  int)  {  h1  > 

par_cause  e1  (n,  n,  1) 
end  ; 

on  e^  (n,  f,  p:  int)  where  l<1  {  h2  } 

par_cause  eQUt  (n,  p)  {  p=factorial(n)  > 

end  ; 

on  e1  (n,  i,  p:  int)  where  i>1  {  h3  } 

par_cause  e-,  (n,  1-1,  i*p)  {  iterate  } 

end  ; 

In  the  optimal  solution,  the  rates  in  which  events  are  caused  from  each  of  the  event  classes 
e)n,  e-j,  eQUt  are  all  equal,  say  to  Fm.  The  rates  in  which  instances  of  h-,  or  h2  are 
activated  are  also  equal  to  Fm>  However,  the  rate  in  which  instances  of  h3  are  activated  is 
0.  The  optimal  solution,  therefore,  assumes  that  for  each  input  event  ejn(n)  either  n=0  or 
n=1.  The  maximum  throughput  of  the  program  really  occurs  in  this  case,  but  it  may  be  not 
realistic  to  assume  that  all  Input  events  satisfy  the  above  assumption. 


Can  we  add  Information  to  the  model;  e.g.,  that  n  assumes  values  in  the  range 

0-4  with  equal  probabilities?  The  answer  is  positive.  According  to  the  added  information 

Fh(i  =  -  (1  +  1  +  -  +  -  +  -)  F_  =  —  Fa  .  Similarly,  Fh  «  (1  -  — )  F_  =  F_  .  The 

n2  5  2  3  4  e1  00  e1  "3  00  ®1  00  *1 

solution  is  to  distinguish  between  events  of  class  e^  activating  Instances  of  h2,  and  those 


activating  instances  of  h3. 


The  way  to  express  such  Information  In  our  model  in  a  general  case  is  as  follows. 
Suppose  e  is  an  intermediate  event  class  identifier  (i.e.,  e/ejn  and  e^e^j)  which  appears  in 
the  headings  of  h^,  ...  ,  hn,  once  In  each  event  descriptor  list,  and  It  Is  known  that 
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(1 )  =  oijFe  for  i«1, ... ,  n  where  «*|>0. 

e  can  be  replaced  by  a  new  set  of  event  class  identifiers  e-j,  ...  ,  en;  e(  will  replace  e  in  the 
heading  of  h}.  if  for  the  original  program  C0h=K,  it  is  now  replaced  by  n  constants  C0(h=ICo*j. 
Each  instance  of  h  causes  Kac-t  events  from  event  class  e|  instead  of  K  events  from  event 
class  e.  The  new  linear  programming  solution  is  a  more  accurate  estimate  of  the  throughput, 
but  it  is  no  longer  a  bound  on  the  original  problem  throughput.  It  is  a  bound  on  the 
throughput  if  (1)  above  is  considered  to  be  a  given  constraint. 


K  is  an  integer  and  K*j  is  not  necessarily  an  integer;  this  poses  no  difficulty  in 

the  analysis.  Note  that  (2)  the  constants  <*|  satisfy  Y  «*|  =  1 ,  or  Y  Fh  *  F  =  0.  The  above 

I  I  1 

follows  from  the  following  two  observations:  First,  (3)  Y  Fhj  <  F0  since  each  imte  an 
instance  of  h=  is  activated  it  uses  one  event  from  event  class  e.  Second,  (4)  Y  Fh  >  F  • 


I 


otherwise  events  from  class  e  will  accumulate  in  the  system.  Events  cannot  accumulate  in 
our  model;  this  can  be  seen  by  summing  equation  B.1  over  all  n.  From  (1),  (3),  and  (4)  we 

i 


get  F0  =  Y  Fh.  *  F0  Y  «£j,  or  F0  (  Y  oTj  -1)  =  0;  this  explains  claim  (2)  above. 


I 


I 


Suppose  h  is  an  event  handler  with  a  script  which  specifies  an  event  whose 

class  designator  f  is  a  formal  parameter  of  the  event  handler,  f  may  be  bound  to  different 

event  class  identifiers  in  different  Instances  of  h.  How  can  the  appropriate  information 

about  f  be  expressed  In  the  linear  programming  constraints?  Consider  a  simple  case  in 

which  any  instance  of  hj,  ...  ,  hn  causes  activation  of  an  instance  of  h  in  which  f  is  bound  to 

e;  and  other  event  handlers  activate  Instances  of  h  in  which  f  is  bound  to  oth.<r  event  class 

identifiers.  In  such  case,  instances  of  h  cause  events  from  class  e  in  a  frequency  (5) 

Y  Fh .  This  sum  can  be  included  In  a  conservation  equation  for  events  of  class  e. 
i  i 
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In  more  general  cases,  one  can  find  the  set  S  of  event  class  identifiers  to  which 
f  can  be  bound.  S  can  be  found  by  a  simple  algorithm  which  uses  transitive  closure.  Without 
such  algorithm,  an  assumption  that  S  contains  ait  event  class  identifiers  in  the  program  can 
be  made;  this  assumption  can  only  result  in  a  higher  bound  on  the  throughput.  Suppose  f 

can  be  bound  to  ej . em;  h  can  be  replaced  by  m  distinct  event  handlers  h-,,  ... ,  hM. 

Each  hj  specifies  in  its  script  an  event  from  class  6j  instead  of  the  event  associated  with 
the  formal  parameter  f.  The  throughput  of  the  original  program  cannot  be  higher  than  that  of 
the  modified  program. 

'I 

The  above  scheme  can  yield  a  throughput  bound  which  is  higher  than  the 
maximum  possible  throughput.  A  refinement  of  the  above  approach  can  be  made  if  some 
control  flow  analysis  (or  another  source  of  information  such  as  the  user)  relates  the 
frequencies  in  which  f  is  bound  to  various  event  class  identifiers  to  other  frequency 
variables  such  as  in  (5)  above.  We  shall  not  pursue  this  direction  further. 

B.3  Other  Event  Types 

So  far  we  have  only  dealt  with  single_use  recurrent  events.  Let  us  examine 
the  difficulties  posed  by  other  event  types;  starting  with  single_use  non_recurrent 
events.  If  slngle_use  non_recurrant  events  are  treated  as  if  they  are  slngle_use 
recurrent  events,  the  solution  to  the  linear  programming  problem  may  be  smaller  than  the 
maximum  possible  throughput.  The  reason  is  that  computational  resources  (CPU  time  and  ink 
capacity)  may  be  allocated  in  the  analysis  to  process  events  which  in  fact  do  not  occur. 
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Suppose  e  Is  of  a  single_use  non_recurrent  type  and  an  event  of  class  e  is 
specified  in  the  script  of  h.  Some  way  to  describe  the  fact  that  an  instance  of  h  can  cause 
zero  or  one  events  from  class  e  Is  needed.  The  solution  is  quite  simple.  A  new  event 
handler  h1  is  added;  the  difference  between  h  and  h-j  is  that  an  instance  of  the  latter  does 
not  cause  an  event  from  class  e.  The  procedure  can  be  repeated  for  all  event  handlers  and 
all  event  class  identifiers  of  slngle_use  non_rocurrent  types.  If  the  script  of  h  specifies 
one  event  from  each  of  n  distinct  slngle__use  non_recurrent  event  classes,  2n-1  new 
event  handlers  are  added. 

Another  approach  can  be  taken  if  some  information  is  known  about  e.  For 
example,  Ceh  (which  originally  was  1)  can  be  replaced  by  <*<1  to  reflect  the  fact  that  the 
rate  in  which  instances  of  h  cause  events  from  class  e  is  only  «*Fh. 

Our  model  cannot  handle  multi_use  events  in  general.  The  reason  Is  that  this 
model  can  only  handle  intermediate  events  which  are  used  (consumed)  by  the  program  In  the 
same  rate  in  which  they  are  caused.  Since  multi_use  events  are  never  consumed,  the 
above  condition  can  be  only  satisfied  if  both  rates  are  zero.  Suppose  e  is  of  a  multi_use 
type.  Simply  selecting  U0^=O  for  all  h,  and  C0h>O  (according  to  the  script  of  h)  will  result  in 
F^=0  for  each  h  satisfying  ceh>°- 

In  certain  cases  multi_use  events  can  be  handled  in  our  model.  Suppose  all 
event  handlers  in  the  program  are  slngle_use  event  handlers  and  It  is  known  that  e  can  be 
implemented  as  a  record  variable  (as  described  in  chapter  7).  If  the  script  of  h  specifies 
n>0  events  from  class  e  and  e  appears  in  m>0  event  descriptors  in  the  event  descriptor  list 
of  h,  one  can  simply  select  C0h=n  and  U0h=n  (independently  of  m).  If,  however,  n=0  then 
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one  can  select  Ceh=U0h=O. 

B.4  The  Effect  of  Managers 

This  section  shows  how  maximum  possible  throughput  of  a  given  program  on  a 
given  network  can  be  calculated  when  our  particular  implementation  scheme  (including 
managers)  Is  chosen.  At  first,  the  problem  may  seem  not  a  simple  one  because  of  the 
Interaction  among  the  managers.  However,  simplifying  assumptions  can  be  made  since  we 
are  interested  in  finding  a  bound  on  the  throughput;  these  assumptions  are  made  explicit  in 
the  sequel. 

For  each  event  class  identifier  e,  there  is  a  corresponding  ECM  me;  similarly,  for 
each  event  handler  h,  there  is  a  corresponding  EHM  mh.  In  this  section  we  assume  that 
each  manager  resides  on  one  node  of  the  network  and  never  moves.  The  node  on  which 
each  manager  resides  is  obtained  from  the  solution  to  the  object  distribution  problem  or  from 
another  source.  Several  copies  of  the  script  of  an  event  handler  h  can  exist  in  various 
nodes  of  the  network;  m^  can  send  an  activation  message  to  any  of  these  nodes  in  order  to 
activate  an  instance  of  h.  The  managers  and  the  scripts  interact  in  a  well  defined  manner. 
Figure  B.1  shows  the  possible  interactions  among  managers  and  scripts  for  a  program 
containing  2  event  handlers  and  3  event  classes.  Several  scripts  of  each  event  handler 
exist. 
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Figure  B.1  The  interactions  among  managers  and  scripts 


An  arc  going  from  to  hj  represents  activation  messages.  An  arc  going  from  h( 
to  mej  represents  event  objects  from  class  ej  caused  by  Instances  of  h|.  An  arc  connecting 
managers  m,  and  mj  represents  messages  exchanged  between  mj  and  mj.  The  maximum 
throughput  is  found  similarly  to  section  B.2.  The  difference  is  that  messages  to  (from) 
managers  and  CPU  requirements  of  managers  are  taken  Into  account.  The  terminology  for  the 
following  analysis  is  shown  In  Table  B.1. 


The  total  rate  in  which  instances  of  h  are  activated  is: 

88  Fh  =  £  Fhn 

n 

The  total  rate  in  which  events  from  class  e  are  caused  is: 

B-9  Fe  =  I  CehFh  ♦  I  Fe| 

h  hL|n 

Conservation  equations  can  be  written  for  the  various  types  of  messages  In  the  model. 
Conservation  of  events  must  hold  for  all  e,  n: 


D(Fe,)*ICehFhn-Mm  nFes° 

h  • 


Note  the  difference  between  equations  B.1  and  B.10.  Here,  the  term  Y  uehFhn  does  not 

h 

appear  since  event  objects  from  class  e  are  sent  to  me  and  not  directly  to  Instances  of 
event  handlers.  Activation  messages  from  m^  to  any  node  n'  must  be  conserved;  thus,  for 
all  h,  n,  n': 


8<Fmhn'l>  ♦  MmhnFhn-  "  Fhn'  *  0 
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l>  +  MmHn  <*1Fh  +  *:2Fe)  '  Mmen  <*1Fh  +  *2Fe>  ~  0 


mhmer  "'h 


where  EQ(n,n')s1  iff  n=n\  else  0.  Conservation  of  messages  from  an  EHM  to  an  ECM  must 
hold;  thus,  for  all  e,  h  (e*h),  n: 

B.12  D(F„ 

<*i  and  oi2  are  constants  which  can  be  selected  according  to  the  assumptions  on  the  way 
mh  and  me  interact,  represents  the  number  of  messages  m^  sends  to  me  In  order  to 
acquire  an  event  it  has  previously  selected.  *c2  represents  the  number  of  messages  mh 
sends  to  me  in  order  to  check  if  an  event  of  class  e  matches  the  heading  of  h.  For  the 
purpose  of  finding  maximum  throughput  we  can  select  <x.2=0.  A  similar  constraint  on 
messages  from  an  ECM  to  an  EHM  must  hold;  thus,  for  all  e,  h  (e'ti),  n: 

B-13  D(Fmemhl>  +  Mmen  <*1Fh  +  *2Fe>  “  M>"hn  (*1Fh  ♦  *2Fe>  =  0 

The  roles  of  fiy  and  fi2  are  analogous  to  those  of  otj  and  oc2  respectively.  In  this  model  we 
assume  that  messages  to  the  output  links  of  the  network  are  sent  by  m0  Conservation 


“out 


of  these  messages  must  hold;  thus,  for  all  n: 


B.1 4 


D(F, 


“out 


-out1 


l>  +  M, 


m. 


“out 


n' m. 


“out 


out 


Since  there  is  only  one  output  event  class,  the  following  must  hold: 


B.1 5 


FmeLout  *  °  f°r  a"  e*e°ut 


The  rate  in  which  events  arrive  to  mQ  must  be  equal  to  the  sum  of  the  rate  In  which  they 
are  used  and  the  rate  in  which  they  are  sent  to  the  output  links;  thus,  for  all  e: 

B-18 

The  link  capacity  constraint  now  includes  more  terms  than  equation  B.2;  for  all  I: 

B.1 7  11  TelFel  +  ^m^n'^m^n'l  +  ^  TmhmelFmhmel  +  Tmem^lFmemhl  + 

e  h,n'  h,e  e.h 


♦  T, 


“out 


out1 


lrm«, 


“out 


■out1 


I  S' 


Note  that  variables  or  constants  of  the  form  Fx(,  Tx(,  Rx),  Sx(,  where  x  is  memh  or  mhme  are 
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only  defined  If  e*h;  thus,  the  qualification  e*h  Is  not  needed  in  the  above  inequality  (and  In 
similar  cases  In  the  sequel). 


K(x)  defines  the  communication  overhead  of  receiving  and  sending  messages  of 
class  x  on  node  n. 


K(x)  =51  Y  RxnFx,  *Y  Y  SxnFxJ 

x  hl(n)  x  ftO(n) 

If  x  Is  a  list  (e.g.,  m^me),  Y  above  is  a  multiple  summation.  For  each  node  n,  the  following 

x 

CPU  constraint  should  hold: 

B.18  K(e)  ♦  K(mhn')  +  K(mhm0)  ♦  K(m0mh)  +  K(m0  L^t)  ♦  Y  PhnFhn  ♦ 

h 


+  £  Mmenpmen(Fe  “  Fm0Lout)  +  £  Mmenpm0L0UtFmeL0ut  + 


e  e 

+  £  Mmhn<pm„hnFh  +  ^  pmhenFe>  *  1 
h  e:  e*h 

The  first  6  terms  of  B.18  should  be  clear  now.  The  next  two  terms  represent  the  load  of  all 

ECM's  residing  on  node  n.  Pm  n  is  the  CPU  time  to  process  an  event  from  class  e  by  me  on 

© 

node  n  Including  handling  all  relevant  messages,  If  the  event  Is  used  by  the  program. 
pm  Lout  18  *  similar  coefficient  associated  with  an  event  sent  by  me  to  the  output  links. 
The  last  term  represents  the  load  of  all  EHM's  residing  on  node  n.  Pm^hn  is  the  CPU  time 
required  by  m^  on  node  n  in  order  to  acquire  an  event  collection.  Pm^an  is  the  CPU  time  to 
process  an  event  from  class  e  by  m^  on  node  n  without  acquiring  it.  For  the  purpose  of 
finding  the  maximum  throughput  Pm^en  can  be  selected  as  0. 


The  flows  on  Input  links  and  output  links  are  restricted  as  follows: 


B.1B 


F„i  =  0  for  all  xfain  and  bL._ 
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B.20  Fx,  *  0  for  ail  x*me  Lout  and 

OUT 

Ail  frequencies  and  flows  must  be  non-negative;  thus,  for  all  e,  h,  I,  n,  n‘: 


021  Fhn*  F«'*  ’"h"'1’  F",hme1'  Fmemh1’  FmeoutLoutl  1  ° 

The  objective  function  to  be  maximized  is: 

B.22  Z  =  I  Fe)n, 

^n 

In  order  to  obtain  a  throughput  bound  which  is  closer  to  the  actual  throughput, 
more  constraints  can  be  added  to  the  above  set  of  constraints.  Such  constraints  can 


describe  limitations  of  a  specific  implementation  of  a  manager  (e.g.,  the  maximum  f;  equency 
in  which  it  can  iterate),  or  available  memory  on  a  node.  The  various  extensions  to  the  basic 
throughput  analysis  discussed  in  the  previous  sections  can  also  be  applied  to  the  analysis 


of  this  section. 


B.5  Throughput  Analysis  Summary 


It  is  Interesting  to  compare  the  maximum  possible  throughput  of  a  program 
obtained  without  our  specific  implementation  (section  B.2)  with  that  obtained  if  the  effect  of 
managers  Is  taken  Into  account  (section  B.4).  This  could  show  how  much  of  the  possible 
throughput  is  lost  due  to  our  managers  overhead.  Unfortunately,  in  both  cases  the  maximum 
throughput  cannot  be  expressed  as  a  closed  formula  in  general;  thus,  such  a  comparison  can 
be  made  only  by  solving  the  linear  programming  problems  and  comparing  the  obtained  values. 


The  linear  programming  approach  can  be  used  not  only  for  analyzing  a  given 
program  on  a  given  network,  but  also  for  analyzing  the  effects  of  varying  some  of  the 
system  parameters  on  the  maximum  throughput  of  a  program.  For  example,  the  effect  of 
adding  (removing)  a  processor  or  a  link  to  the  network,  changing  the  capacity  of  a  link, 
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changing  the  speed  of  a  processor,  totally  changing  the  network  topology,  or  modifying  the 
algorithm  of  an  EHM  or  an  ECM  can  be  found. 
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Appendix  C  -  Data  Flow  Performance  Evaluation 


This  appendix  develops  performance  bounds  for  a  limited  class  of  EBL  programs 
on  the  data  flow  processor.  The  class  of  programs  captured  by  the  following  discussion  Is 
identical  to  that  of  section  B.l.  First,  a  method  for  computing  bounds  on  the  maximum 
possible  throughput  which  is  not  based  on  a  specific  implementation  scheme  is  presented. 
Then,  a  method  which  specifically  refers  to  our  manager  based  implementation  scheme  is 
given.  The  methods  are  similar  to  those  given  In  appendix  B  for  a  processor  network. 


For  the  analysis,  the  processor  will  be  represented  by  the  model  of  Figure  C.l. 


Figure  C.l  The  routing  networks 

We  assume  that  the  arbitration  network  consists  of  three  parts:  aQ,  af,  and  am;  and 
similarly,  the  distribution  network  consists  of  three  parts:  dc,  df,  and  dm.  We  will  call  the 
above  sub-networks  routing  networks.  Input  events  enter  the  distribution  network  at 
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output  events  leave  the  arbitration  network  at  aQut. 

Most  of  the  terminology  is  similar  to  that  used  in  appendix  B.  Additional 
terminology  is  defined  in  Table  C.l. 

an  operator  performing  a  fixed  function  (e.g.,  addition,  memory  access) 
the  number  of  identical  units  of  f  in  the  system 
a  routing  network  (r=ac,  af,  am,  dc>  df,  dm) 

the  frequency  of  events  of  class  e  entering  at  djn  (destined  to  me) 
the  frequency  of  events  of  class  e  leaving  at  aQUt  (sent  by  me) 

the  total  time  taken  by  all  packets  related  to:  (1)  a  message  of  class  x 
(x=e,  medjn,  meaout,  or  m0e),  or  (2)  all  messages  required  for  the 
execution  of  an  Instance  of  x  (x=h,  m^e,  or  m^h),  traversing  routing 
network  r 

the  total  time  required  for  processing  all  packets  related  to:  (1)  a 
message  of  class  x  (x=e,  medin,  meaQut,  or  mee),  or  (2)  the  execution  of 
an  instance  of  x  (x=h,  m^e,  or  m^h),  on  operator  f 

denoted  by  X: 

as  defined  earlier 

an  event  of  class  e  arriving  from  djn  destined  to  m£ 
an  event  of  class  e  sent  by  m0  to  aQUt 

an  event  of  class  e  caused  by  an  instance  of  some  event  handler  (i.e., 
not  arriving  from  djn)  and  used  by  an  instance  of  some  event  handler 
(i.e.,  not  sent  to  aQUt) 

processing  an  event  from  class  e  by  mh  (eAh)  without  acquiring  it 
acquiring  an  event  collection  by  m^ 

Table  C.l  Data  flow  throughput  terminology 

C.l  Maximum  Possible  Throughput 

This  section  starts  by  showing  how  bounds  on  the  maximum  possible  throughput 
can  be  computed.  It  first  assumes  that  enough  copies  of  the  script  of  each  event  handler 
exist  in  the  instruction  memory.  This  assumption  is  relaxed  later  in  this  section.  The 
constraints  are  analogous  to  those  of  appendix  B.  The  frequency  in  which  events  of  class  e 
are  caused  equals  the  sum  of  the  frequency  In  which  events  of  class  e  are  used  and  the 


Classes 
e,  h 

medin 

me®out 

mee 


mhe 

mhh 


f 

"f 


Fedin’  Fmedjn 

Feaout’  Fmea0ut 

Txr 


xf 
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frequency  In  which  events  of  class  e  leave  the  system;  thus,  for  all  e: 


C.l 


Fe  =  cehFh  *  Fed. 


in 


C.2 


F*  =  £uehFh  +  Fea. 


out 


The  constraints  on  the  routing  networks  are: 


C.3 


Tgf(Fg  *  Fea  .)  ^  1  for  r  -  am,  d 


out 


m>  "m 


C.4 


£  ThrFh  *  1  for  r  a  af  df 
h 


C.5 


TeacFe  *  ThacFh  -  1 


C.6 


^  Tedc^Fe  “  Feaout^  *  ^hdcFh  -  1 


e  h 

The  total  capacity  of  the  n^  operators  of  type  f  must  not  be  exceeded;  thus,  for  all  f: 

C  7  I  PhfFh  <  nf 

h 

The  memory  is  viewed  as  an  operator.  Events  arriving  through  djn  must  be  of  class  e(n: 


C.8 


Fed  ■  0  for  all  e#ej 


in 


In 


Similarly,  events  leaving  through  aQUt  must  be  of  class  eout’ 


C.9 


ea. 


out 


*  0  for  all  e»*e, 


out 


All  frequencies  and  flows  must  be  non-negative;  thus,  for  all  e,  h: 


C.10 


Fh>  Fe’  Fedi_’  Fea, 


In  ““out 


>  0 


The  objective  function  to  be  maximized  Is: 


C.11 


Z  «  F 


elndin 


The  above  analysis  assumes  no  limitation  on  the  number  of  copies  of  the  script  of  an  event 


handler.  If  there  are  nh  copies  of  the  script  of  h,  executed  as  nh  pipelines,  then  the 
following  constraint  must  be  added  for  all  h: 


Maximum  Possible  Throughput 
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c-12  Fh  ^  nhFh  max 

Fh  max  is  the  maximum  frequency  in  which  one  copy  of  the  script  of  h  can  be  executed  in 
pipeline  mode.  Fh  max  can  be  computed  for  any  given  h  if  minimum  delay  times  of  the -routing 
networks  and  minimum  execution  times  of  all  operators  are  known. 


C.2  The  Effect  of  Managers 


Maximum  possible  throughput  when  managers  are  taken  into  account  can  be 

N 

computed  analogously  to  the  scheme  of  section  B.4.  The  terminology  is  defined  in  Table  C.1. 
Like  equations  C.1  and  C.2,  the  frequency  in  which  events  of  class  e  are  caused  equals  the 
total  frequency  in  which  they  are  used  or  leave  the  system;  thus,  for  all  e: 

C.1 «  Fe  =  ^cehFh  +  Fmed,n 

h 


C.1 4 


Fe  =  ^  uehFh  +  rm0aout 


There  are  constraints  on  the  six  routing  networks;  thus,  for  r  =  ac,  a^,  am,  dc,  df,  dm: 
C1 6  ^  T«neer<Fe  '  Fmed|n  "  Fm0aout)  +  £  Tmed|nrFmed|n  «■  I  TmeaoutrFmeaout  + 


♦  E  <TmhhrFh  +  E  TmherFe>  *  E  ThrFh  <  1 
h  e:  e'Ti  h 

The  first  three  terms  represent  activities  of  all  ECM's;  the  fourth  term  represents  activities 
of  all  EHM's;  and  the  last  term  represents  activities  of  all  instances  of  event  handlers.  The 
constraint  on  the  n^  operators  of  type  f  contains  similar  terms;  for  all  f: 


Section  C.2 
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C16  ^  P*eef<Fe  ‘  Fmedjn  "  Fmeaout>  +  ^  Pn»edinfFmedin  *  ^  Pn»e»outfFmeaout  + 


+  (Pm^hfP h  +  Fm^efFe^  +  **hfFh  -  nf 

h  e:  e*h  h 

The  constraints  on  input  and  output  from  the  system  are: 

C.A7  Fmed,n  =  0  for  8,1  e*ein 

c-18  Fme*outS°  for  811  e**out 

All  frequencies  and  flows  must  be  non-negative;  thus,  for  all  e,  h: 


C.1 9 


Fh>  Fe>  Fm_di_’  Fm„a, 


euln  ,ne"out 


>  0 


The  objective  function  to  be  maximized  Is: 


C.20 


2  =  F, 


m‘»lnd'" 


As  in  the  previous  section,  more  constraints  can  be  added  to  describe  further  limitations 
imposed  by  a  specific  implementation  scheme.  For  the  n  pipelines  scheme,  (like  C.1 2)  for  all 
h: 


C.21 


Fh  -  nhFh  max 


C.3  Throughput  Analysis  Summary 


The  linear  programming  approach  can  be  used  not  only  for  analyzing  a  given 
program  on  a  given  data  flow  processor,  but  also  for  analyzing  the  effects  of  varying  some 
of  the  system  parameters  on  the  maximum  possible  throughput  of  a  program.  For  example, 
the  effect  of  adding  (removing)  an  operator  to  the  processor,  changing  the  capacity  of  a 
routing  network,  or  modifying  the  algorithm  of  an  EHM  or  an  ECM  can  be  found.  The  various 
extensions  to  the  basic  throughput  analysis  discussed  in  appendix  B  can  also  be  applied  to 
the  throughput  analysis  of  this  appendix.  It  is  Interesting  to  compare  the  maximum  possible 
throughput  of  a  program  on  a  network  with  the  maximum  possible  throughput  of  the  program 
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on  the  data  flow  processor.  Unfortunately,  such  a  comparison  can  be  made  only  by  solving 
the  linear  programming  problems  and  comparing  the  obtained  values. 
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